Force Linden Labs To Restrict The Grid
|
|
Gordon Wendt
404 - User not found
Join date: 10 May 2006
Posts: 1,024
|
04-04-2007 17:00
From: Haravikk Mistral I posted a version of my suggestion on having auto-blocking triggered by network stress to the JIRA tool: https://jira.secondlife.com/browse/SVC-87The summary being: A computer somewhere monitors the network periodically. It takes the peak network bandwidth (the highest recorded amount of outgoing the data the network was able to sustain for some reasonable period, refreshing of course in the event some part of the network goes down so this stat would go down too) and divides by the number of people online, thus getting the bandwidth each person online can reasonably expect from the system. If this value (bandwidth per person) drops below some acceptable minimum (say 256 or 512kbps given the nature of SL) then the blocking will come into effect, immediately blocking unverified log-ins. If the minimum is still not achieved, then verifieds are blocked too, meaning premium only. It also mentions doing the same to simulators in the event of frame-rates falling (opposed to being by capacity). This gives huge incentive to verifying and maybe getting premium, hopefully increasing the cash available to LL to better account for growth of the grid/more users online. So as premium members grow, the grid can grow for them with the money they provide, with the non-premiums getting to access the grid during the less busy periods. I like the concept, I like the first part about restricting no payment info's but I think your nuts if you think A) anyone will support stopping login from non preimiums, and B) if LL would ever implement them considering how stupid a business and PR decision it would be.
|
|
Serenarra Trilling
Registered User
Join date: 14 Oct 2006
Posts: 246
|
04-05-2007 05:24
The thing is, Gordon, SL already said they WOULD do this. But then they didn't. To me that inconsistency is the worst part of it.
|
|
Inigo Chamerberlin
Registered User
Join date: 13 May 2006
Posts: 448
|
04-05-2007 06:24
From: Winter Phoenix Unless we all have a sick out, and don't show up some weekend. GREAT idea! The 'weekend' is Friday night to early Monday morning (GMT) for me - 60 hours maybe, out of the 168 in a week, most of the rest I'm too busy IRL to use. Soooo, I, no, we, should give up our SL time, which we PAY for, AND thereby lower the load on the creaking grid - to put PRESSURE on LL? Think about it. All that would do is help them. The only pressure LL will ever react to - and then WAY too late, as always, is seeing their income slashed. And that, realistically isn't going to happen until a credible competitor is available. At which point we don't need LL any more anyway - game over for LL.
|
|
Brenda Connolly
Un United Avatar
Join date: 10 Jan 2007
Posts: 25,000
|
04-05-2007 06:38
Maybe one way to voice your opinions, for those whose pemiums are due, renew monthly. I don't know haow much LL gets from the yearlys, but it may be noticeable? What is the benefit of yearly renewal, besides the insignificant, in my opinion, discount?
_____________________
Don't you ever try to look behind my eyes. You don't want to know what they have seen.
http://brenda-connolly.blogspot.com
|
|
Inigo Chamerberlin
Registered User
Join date: 13 May 2006
Posts: 448
|
04-05-2007 08:37
From: Brenda Connolly Maybe one way to voice your opinions, for those whose pemiums are due, renew monthly. I don't know haow much LL gets from the yearlys, but it may be noticeable? What is the benefit of yearly renewal, besides the insignificant, in my opinion, discount? Again, monthly costs more per year than yearly - so LL would LOVE you to pay them MORE per year  Like I said, the only way for people to get the message across is to grab you bat and ball and go home... en-mass
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
04-05-2007 09:06
From: Gordon Wendt I like the concept, I like the first part about restricting no payment info's but I think your nuts if you think A) anyone will support stopping login from non preimiums, and B) if LL would ever implement them considering how stupid a business and PR decision it would be. Problem is though, that if the system is under enough stress that it has to start blocking non-premiums, then it's going to be a poor experience for both premiums AND non-premiums anyway, IMO that warrants choosing one over the other to try and deliver the best possible experience to those that are paying for it. The way I see it, a premium's major worth is in the ability to own land, but it's no longer possible to get first-land (which was becoming a pain to get anyway) which drops the value of premiums considerably. However, they are still paying for the service, with or without first-land, which I think gives them the right to expect better guarantees of service. Of course I'd hope that the first-stage (blocking unverifieds) would sort the issue, since it should in theory prevent the bandwidth per person ever dropping below a reasonable minimum, but if it doesn't after some period of time, then further measures need to be taken.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
|
Meade Paravane
Hedgehog
Join date: 21 Nov 2006
Posts: 4,845
|
04-05-2007 09:40
From: Haravikk Mistral [throttle logins based on current system network usage] If they were to somehow limit people based on how much they pay out, an idea I'm not overly partial to, I think it would be better limit access to the asset servers. Everything in SL has a UUID and (I assume) every UUID has some generic info that goes with it - name, creator, etc. If a "load" (as in "system load"  property was added to the per-UUID info, they could place limits on inventory. Say, maybe, no-payments get to keep a max load of 1,000 in their inventory and payment-but-not-premium get to keep 10,000. I don't know enough about the internals of LL to suggest a formula for figuring out the load of an object but things like prim count, script count, how unlikely it is to be cached, whether or not it's physical, etc could go in there. I still think, sorta as I said in a previous post here, that most of the problems we see aren't due to SL bumping into networking limits. I don't doubt that SL could take 50-60k online at once if they were just all standing around talking. The problems start when everybody is changing clothes and rezzing objects and such.
_____________________
Tired of shouting clubs and lucky chairs? Vote for llParcelSay!!! - Go here: http://jira.secondlife.com/browse/SVC-1224- If you see "if you were logged in.." on the left, click it and log in - Click the "Vote for it" link on the left
|
|
Artillo Fredericks
Friendly Orange Demon
Join date: 1 Jun 2004
Posts: 1,327
|
04-05-2007 12:01
My 2 cents; It sounds to me like many of you posting here don't have much of a clue as to how SL actually works. You need to separate two different types of "lag", slowdown. etc that people are referring to. From my understanding, it breaks down something like this: Even though the entire world is called "the grid", that does NOT imply that it is ALL contigous and subject to slowdown "grid-wide". Each sim is ONLY connected to the adjacent sims next to it, and object and avatar data is passed from sim to sim as you move between them (or are rezzed if you are within draw distance). Then there's asset server slowdown, which is more likely the culprit that most people are talking about. That's stuff like your inventory loading real slow or not loading at all, missing textures, objects, etc. that the server is pulling that info in for. Seems to me that LL should just bump up the number of asset servers to reduce that kind of lag. I doubt there's much lag on the chat server end of things, either. Ask an oldbie what it was like in SL when they used to have a tax on each thing you rezzed in world, trust me things are a lot better now than they used to be!
_____________________
"I, for one, am thouroughly entertained by the mass freakout." - Nephilaine Protagonist --== www.artillodesign.com ==--
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
04-06-2007 04:37
The lag I'm talking about is however definitely not simulator or asset server related; The first because by opening the debug info (Shift - Control - D) it is clear that the simulator is operating at the optimal 45fps for both graphics and physics. The only stat that is dropped is agent updates/sec, which is dropped because updates aren't getting to me (which brings down the average). That and packet loss, which from the other stats is not the fault of the simulator. The second because I've already downloaded everything. I'm not touching the asset server at all at this point.
In other words, I'm in my home location, with nothing changing within range of me that would need to be downloaded. Bandwidth usage, and pending downloads never change. The issue only occurs when I am trying to either move, or to talk to someone at which point the packet loss starts to kill me as I judder about, things I'm editing don't move or snap back and so-on. In this instance, packet-loss means exactly what it means, of all the packets the simulator is trying to send to me, 20% or more are simply not making it before they expire (ie are useless because the information they contain is too old).
The conlusion therefore is that something is causing a bottleneck between the simulator (which is functioning fine) and my machine (which is also functioning fine, FPS is high so long as I don't do anything which relies on an update from the sim). This could be put down to my connection or such, but thing is, this doesn't happen when there are 24,000 or less avatars on the grid. Only when this number gets higher do things get exponentially worse for me and most people I try in vain to talk to. Thus, whether it is a machine or a connection on SL's network that is restricting the capability for it to get information to me in a timely manner, it is the network that is struggling because it is under a load greater than it can handle. This may be because one person is downloading lots of information, however network traffic is typically shared to some degree, so if I'm getting an average of 100kbps then so should everyone else be, meaning everyone is slowing down, because the bandwidth per-person is far too low to accommodate everyone, and those who are a longer distance away suffer exponentially worse as a result.
It then makes sense that limitting the network when it gets too over-worked will solve the issue during peak-times, as even if the network is still saturated, with less people struggling to get their data, more of it will get through meaning that everyone who is on will get a more playable game. You see the exact same thing with all kinds of networks, not just computing ones. Rail networks cut down the number of passengers at peak-times by denying access to people who have opted for cheaper/special-offer tickets opposed to standard-fare or business class tickets. This reduces the number of passengers (load) on the trains and results in less people having to stand (an undesirable experience) during these times of higher traffic.
The system I'm proposing expands easily with the network, so if LL later fix whatever is causing the network to become overloaded by adding more machines or getting a bigger connection, then the recent maximum sustained bandwidth stat will go up, thus more people can be allowed on before the bandwidth per-person drops too low. But it is simply senseless to allow more people onto the grid than it can reasonably handle, as all it does is hurts the game for everyone and cripples the experience of people playing and participating on SL.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
|
Draco18s Majestic
Registered User
Join date: 19 Sep 2005
Posts: 2,744
|
04-06-2007 08:05
From: Artillo Fredericks My 2 cents; It sounds to me like many of you posting here don't have much of a clue as to how SL actually works. You need to separate two different types of "lag", slowdown. etc that people are referring to. From my understanding, it breaks down something like this: Lag Type #3: Network Lag.
|