Jump to content

WolfBaginski Bearsfoot

Resident
  • Posts

    1,238
  • Joined

  • Last visited

Everything posted by WolfBaginski Bearsfoot

  1. Since the network and server maintenance on the 25th September, Kuula sim seems to have been going up and down like a yo-yo (I have a cruder English version of that which leads to the suggestion that she should have used stronger elastic). With neighbouring sims also vanishing, sometimes all eight neighbours, leaving red-marked sones on the mini-map and nothing but empty space in world, there's something wrong somewhere. The Sim returns to life pretty quickly, though it may be invisible to teleports for several minutes, and other users seem to have been experiencing the same crashes, so it's not all specific to my connection. It's getting annoying (and anyone who suggests making a JIRA report can go copulate with a mirror: that's a time management system, not an error reporting system). William Tare Fox, and other expressions of dismayed and frustrated curiousity as to what is going on.
  2. If you have a problem, if no one else can help, and if you can find them, maybe you can hire the A-Team.
  3. And then we have only recently ended a long period when only a few people, mostly Lindens, were allowed to read JIRAs, so some sort of "is this problem just me" was a good idea. And I don't think the JIRA system is all that good a tool to report problems, not for relatively ordinary users. I reckon we need an interpreter. If you haven't noticed, the last three months have been rough, in a lot of ways. And, with certain honorable exceptions, Linden Labs can seem very unresponsive. If you think this is bad, go hang out in the merchant forums for a week or two. One indicator I use: a few months ago I made a non-stop flight from Bagheera sim to Lenimov sim, pretty much the longest popint-to-point flight possible in SL. The Gridflight group are planning to try that. but I am beginning to wonder if the current quality of sim-crossing is adequate. The problem may well be with my end of the connection, but I have seen a change for the worse. Is it just me? Not from the reports I have heard. Can I prove it to the Lindens or to you? I don't know, but it's not a bet I feel confident in.
  4. I can certify it is NOT a Martian Invasion. The chances of anything coming from Mars are a million to one, they said.
  5. Good to hear it's fixed. You seem to have been trying the right things, different viewer and different accounts. It would have been worth mentioning the region affected, and whichever server version it was running. One of us could have slipped in and seen if they saw the same problems. And sometimes whese things can be down to a bad connection: a rough idea of where in the world you are, US State or similar level, could help distinguish problems at the server end from other problems. It's worth knowing what your usual ping times are
  6. You said: The problem quite frankly is not with these functions. The problem is with the people who use them to abuse. As far as the allegation that LL is too arrogant to answer you, actually they have already answered us on this matter. It's all there in the TOS and the CS. The problem is people don't seem to be able to accept it. A little over a year ago, there was some pretty bad griefing going on. The bad guys would unleash their attacks over the weekend, and there might be nobody around to halt them. Some places were well-run, and there were people available who could kill the griefing objects within a few tens of minutes. But others were not, and that included the Linden rez-zone: no reaction until the weekend was over. And so abusive people are reported to the Lindens. And those accounts, more than a year later, still exist. I have never seen convincing evidence that the Lindens have ever done anything more than a bit of rez-zone clean-up. And, as I have said, I see Griefer accounts still in existence. I cannot tell if they are locked, or why they cannot be deleted if they are, but it makes it hard for me to believe that the Lindens do anything about the abusive people. Granted, not every griefer deserves to lose their account, but the important point is that nothing appears to happen. Why, one might ask, bother to AR a griefer if there is no visible consequence? There are a few Lindens I trust, at a personal level. I know how they behave. I know how they react to reports of problems. But the Governance Team, on what I can see, might be no more than an auto-reply function on a computer (behind a locked door in the cellar with a "Beware of the Egress" sign). That's the problem with griefing.
  7. In the past, I have wondered if the people with the permissions to change the Gris Status Page are working on normal office hours. It would explain the failure to announce the server roll-outs have actually started at the time the process starts. But then there are announcements made late at night. It might be two shifts out of three. If that's the problem, there may be ways around it. Think sudo for an instance of the sorts of password-protected accesses that can be done in Unix-derived systems. Can we trust Grid Status if there are times when nothing can be posted? And then some Linden will tell us that there is such a method. Well, does anybody use it?
  8. The Amex business is intriguing. Any card payment system has controls on how maintenance is carried out. You write and test new code off-line, and that includes testing the installation procedure. Because when you do deploy the new code, or the new hardware, you can't stop half-way through without messing up the transactions in progress. If the Labs have stopped work for the weekend, Amex payments have to be halted. If you're not getting an error message telling you no payments can be made, and any Merketplace purchase isn't properly handled, they're doing something wrong. It's a bit like double-entry bookkeeping: you don't stop until all the entries for a transaction are complete. It's why you should have a UPS on the computer that runs the bookkeeping software. They could be doing all this right, but past performance leaves me thinking that I cannot trust the Grod Status page.
  9. One thing I have noticed, this weekend, is that sim-crossing is far less reliable. I made a non-stop flight, a few weeks ago, totalling 108km, but I wouldn't even try it now. It might be wrong to blame it on the long gap since the the last grid-wide server deployment, and the associated restarts, and the Lindens will be seeing figures that I cannot, but I keep seeing the pattern. There have been great improvements in sim crossing. A year ago, I would have expected the trip I made to fail dismally. But we always see this gradual deterioration when the Grid doesn't get recular restarts.
  10. I;m not sure about the sim-crossing, but the initial burst of activity on login seems excessive. It's a wild guess, but it's as if the bandwidth setting is getting ignored for a while. When stuff all passed through the server, there was a single point of control. Now, with distinct servers for so many different things, it's as if they're all talking at once, and sharing out the bandwidth is taking too long. Sim crossing might have the same everyone at once problem. There's a lot of stuff happens. I don't know what actually happens. I don't know what ingenious schemes are in the works. And I sometimes wonder if anyone knows what will happen when tens of thousands of users, all around the world, hit the servers with their inevitably slower handshaking delays. A friend in the software testing business tells me it is easy to simulate a slow link (Linux box, running a specialised distro, with two ethernet ports, adding controllable delay, jitter, and data loss), but I sometimes wonder who bothers. Is Linden Labs good or bad on this?
  11. Since almost all the third-party viewers use Linden Lab code for most things. this seems an appropriate place to ask. Is the Viewer Cache system doing as good a job as it could? I've a suspicion that the cache management overhead is significant for the TPVs which allow a large cache. Even with a short draw distance, TPing into a region I visit almost every day. there is a burst of texture downloading and scenery staying grey for what feels like a long time. In the time I have been in SL, there have been a lot of changes, and things such as mesh and pathfinding may have affected the significance of the caching choices made by the Viewer's system. The shift to HTTP is another factor that changes things. Does SSA even use the cache: I sometimes see my AV take a long time to rez on login. Is it time to review the caching system, maybe with a larger Viewer cache in mind? Should more be done to cache mesh data? It may not be closely related, but why do attachments vanish without apparent reason?
  12. I have built rigged meshes for other rendering coftware, and making a Fitted Mesh for Second Life is going to be more work. I think it will be a while before having a Fitted Mesh viewer is going to make an obvious difference. Mesh clothes already respond to some changes to Avatar Shape, things such as arm and leg length, so I am hopeful about this. I hope the Marketplace team are doing a better job than when I quit selling in the Marketplace, but I don't have any confidence that they will handle this well. All we can do is urge merchants to be careful of the phrases and keywords they use.
  13. There have been changes to the Mesh system, and I would be inclined to reset that meshmaxconcurrent setting to the default.
  14. The process seems grotesquely extended this week. 5am nominal start 7am announcement in status Still running at time of posting
  15. It's been running for over 36 hours now, and the Server Restarts have begun. They're not going smoothly and, of course, these griefer prims will have to the saved and reloaded as part of the restart process. All the prims I have sampled have the same name and the same creator and owner account. I am beginning to wonder if the AR process is nothing more than a script running on an Atari which sends out those email messages.
  16. I don't know how much is a more general connection woe, but at 12:00 SLT I was unable to even connect to the website. Here we are now, at 22:00 UTC (14:00 SLT), and it has taken about 10 minutes to get to "connecting to region". I know that there was a major griefer attack reported at about 21:00 SLT Feb 02 which had not received any useful response by 12:00 SLT Feb 03. It was using self-replicating scripted prims to overload the Physics engine, and last I was able to check was afflicting multiple regions. As it stands, I can't tell if there is a major connection problem for the SW USA, or Second Life is in the state of being so drunk it doesn't even want to have the car keys in its possession when the cops arrive. It's getting late enough that I may as well forget about Second Life until tomorrow.
  17. I am seeing very regular pulses of packet loss on my connection. Where the cause is, I have no idea. With the shift from UDP to HTTP for so much SL data, I'm not sure what this means. Can you even detect packet loss in UDP? It doesn't seem to affect any other software I use, and errors are not reported in my modem/router diagnostics. Can I trust what the viewer tells me?
  18. You said "Also the stats are only showing the UDP data now. AFAIK, there is nothing that allows us to see the HTTP data flow." When did that start? It makes some of the advice about checking bandwidth use, and about the Preferences setting for a bandwidth limit, look misleading. You may be able to get a useful measure of the total from a system utility. In Windows 7, for instance, there is a network bandwidth monitor function in the Task Manager. But if anything else is using bandwith it'll increase the total. There may be something provided by a firewall program.
  19. There is one thing that might explain it. Are you using an old version of Firestorm? Some of them have been blocked from SL You should see the version number in the info line at the top of the Firestorm window.The current version is 4.4.2 with the 4.5.1 Beta also widely used. It's always worth letting us know the version number for a Viewer problem, any Viewer. The Beta status of 4.5.1 was assigned because they wanted to get a new version out before the end of the year, and I've not experienced any bad behaviour from it. It isn't a bad idea to have an alternative viewer available. For Firestorm the in-world support is excellent, but they will want to know the version number.
  20. A few days ago, the Mainland Sim where I have a land parcel was getting very awkward. After asking around, I was advised that the "Physics Memory Allocated was very high, 440 MB of RAM. I put in a Support Ticket, and got a pretty fast response when LL opened for business. The RAM usage has been between 85 and 100 MB of RAM since then. The Region had been running for 25 days, and it's likely a lot of regions will be working better after a restart, which we can expect on the usual schedule. It would be a good idea to open the Statistics Window and check the Physics Memory currently used, before and after the Restart. I know some sims have been restarted over the last for weeks, and some have not. If the numbers are more-or-less the same after the restart, maybe a restart has been done, maybe you've been lucky. But the post-Restart number is likely a useful baseline to judge a particular region by. And if the number gets over 400 MB, a restart request might be worthwhile. I've not seen any recent figures for how many sims a physical server reports, and how much memory a sim might use, but there are a couple of older examples which suggest 1 GB per sim. 400 MB looks like a lot, and it's just a part of the RAM that a Sim needs.
  21. Just to give a feel for the scale of what it needed for Open Sim and Sim-On-A-Stick I run a 16-region instance on a Windows 7 64-bit machine with 4GB of RAM, plus an instance of Firestorm Viewer. If I were running 32-bit Windows I would have less than 3GB of RAM because so much address space is used for the video card. It's a significant difference in available memory. If you were expecting many users and complicated scenery, 9-region or even 4-region would be a safer choice.
  22. I am seeing a pattern of slow texture delivery which is consitent with a problem affecting the SSA-system. Yes, sometimes my connection is slow, but after excluding cached textures, textures from the SSA servers are consistently slow to be delivered. Even the textures beiung used by my AV when I logged off not five minutes ago. I see that pattern with both Firestorm and Cool VL Viewer. Textures applied to new-to-me objects are always the first non-cached textures to arrive, even when textures are sluggish. The sequence is consistent. I've had baked textures take over ten minutes to arrive, sometimes one texture from the AVs full set.
  23. It's being reported that Gmail is misidentifying email from Linden Labs as spam. It works OK if you have a filter set up to handle such mail.
  24. Started just before 7am, Kuula region down for over an hour to my knowledge, process announced finished at 11:20am, SSA subsequently very sluggish. While I cannot rule out some connection problems for the latter, that's still far slower than usual for an RC roll-out.
×
×
  • Create New...