Jump to content

arabellajones

Resident
  • Posts

    681
  • Joined

  • Last visited

Reputation

377 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There's not such a lot of power used, even by a powerful desktop. There are a lot of changes happening to electricity metering in the UK. The label to be wary of is "smart metering". You don't always have predictable timing for the different rates. Better to pay attention to keeping the heat in the house, whatever rate is charged. I have a place wired for the old Economy 7 system, which has storage radiators connected through a time clock to use cheap rate power. Only thing is, I am now getting charged the same rate on the two meters. Not really relevant to Second Life, but it looks as though people are going to get caught out by such changes. I saw a letter to a newspaper extolling the advantages of overnight cheap-rate electricity. Somebody is going to get a surprise. My computer has an idle/sleep option which I use now. Second Life uses a lot less power than something such as video coding.
  2. This isn't the big issue with what happened on Tuesday, but Second Life runs 24/7 and Linden Lab doesn't. There is a big chunk of every day when things can go wrong—my most recent experience was a region going down—and there seems to be no way of reporting it. I think I could have submitted a JIRA, but that needs a different password, and I can't call it a user-friendly. And, key question, how long before any action gets taken? That applies however the report arrives at Linden Lab. I have had to deal with various fault-reporting services over the last few months, and I know it's not easy. I'm English, but I hesitate to trust speech recognition systems. I have struggled with the accents of some call-centre staff. And a telephone call to North America? Second Life is international in scope, but even with a common language I wonder if it is run to cope with that.
  3. The machine I am using is rather old, but it was a high-end office desktop. It needed a gaming-quality GPU card to handle Second Life. When I look at the numbers for currently-produced computers, what I do see is greatly-reduced power consumption for the same amount of work done. If you're not using the absolute latest kit, it may not matter, but it was hot enough this last summer that it might. If you're not into the specialised solutions, cooling or otherwise, that's OK. Second Life doesn't force you into bragging-rights territory. The only hardware ID in this thread I have recognised is "GTX1050" which is an nVidia GPU. I am not sure their numbering system is the same as it was, but that's basic gaming quality.
  4. The trouble is that the Status Page isn't reliable in the early stages of a problem. Yes, we should check it, and "nothing on the Status Page" is part of a good initial report, but some of us do have tools available to us that others don't. Some people seem able to use the JIRA, but it started as a job-tracker used by management, and I still have doubts about it for bug reporting. I have a suspicion that JIRA is being used in London to manage The Queue. If you can handle the JIRA interface, use it. If you can't...
  5. I have installed the new Firestorm version, released on Friday, and it is running OK on Linux. This is v6.6.3.67470 This does feel like a quick release, but there have been a lot of changes to the SL viewer and this release is playing catch-up. It looks like one change is the handling of group notices. If you have been away for a few days, you will see a lot more accumulated. It's pure luck that I caught it when I did, but there is no need to rush. The download site may be pretty busy. With the Havoc code, the Windows version may feel a bit different.
  6. The problem there may be in the viewer or in the server. "Too-high settings can cause the viewer to request data that is not available." is in the Firestorm web-page on the subject. I haven't found a clear explanation on the Second Life website.
  7. Why is it still called just "bandwidth", which could be misleading? OK, it could be that there isn't room to change the label to "UDP Bandwidth" but I just checked Firestorm and it's not a problem there: plenty of room. Cool VL Viewer does a good job with the pop-up help. Firestorm directs you to a web page for a "suggestion", and I am not sure which is better. I would call the web page an "explanation", but I am English, and so speak a different language. (And it's not JIRA.) I run my "bandwidth" at 350 Kbps for Firestorm. It shows a slider with different recommendations depending on the internet connection type, and I don't think those have changed since the days of UDP-only texture delivery. With the reductions in UDP traffic that sort of reduction works for me, but I am not sure how the bandwidth setting really works. I am not going to assume that every SL-user has an exclusive connection. My bottleneck is the DSL to my ISP, and I could have a family member start downloading a video. I'm OK with my settings, but the internet has changed. SL has changed. Does the "bandwidth" setting need an up-to-date explanation?
  8. In Firestorm that's in Preferences > Graphics > Hardware Settings as anti-aliasing. There's a range of values possible. A restart of Firestorm is recommended, but you don't have to be logged in to SL to change this setting.
  9. It depends a bit what you are doing, but a large hard drive is worth having as well as an SSD. It doesn't have to be an internal drive, USB and Network connections to an external drive are fast enough. And while I have used an SSD for my SL cache, the write-load on an SSD from a cache can certainly be argued about. I don't have a definite best answer, but I would hesitate about an SSD-only system.
  10. This thread is old, not the current week. There are the usual initial warnings on the Grid Status page, posted on Friday. We maybe should always expect restarts on Tuesdays and Wednesdays. But there is a difference between a mere restart and a new server version, and even restarts sometimes take a long time. Kept in the dark and...
  11. In all this talk about textures going missing, whether a texture, a bump-map, or a specular-map, I can see reasons why LL have moved them from being part of the viewer download to being part of the general download-from-server system. But we still seem to have very old defaults for the cache and the download bandwidth, and other elements that could affect these. My understanding is that the "bandwidth" setting only affects UDP traffic, and texture downloads now use HTTP. Most of us have a far higher total download capacity, but are some of us pointlessly increasing that "bandwidth" setting? A bigger-than-default cache size should help, though some of us do have disk-space limits. Could these default textures be better handled by distinct cache-like storage which only deleted a file when an update was available? Done right, this pseudo-cache could be applied to different viewers but I am not sure I could trust the Lindens to get that right. How many people, complaining about these missing-texture problems, have even bothered to report their cache-size?
  12. To "some" RC channels? So how do we know which regions even have the bugfix? I suppose we have to check for server version 2022-08-24.574550 We do have the usual warning notices for next week, but they are so vague and so automated that I wouldn't rely much on them.
  13. There are going to be RC Restarts, Friday, starting very soon, to partially fix this problem. "Scheduled for Aug 26, 07:00 - 15:00 PDT " That was posted to Grid status yesterday, but no mention in this forum. And it's only described as a partial fix.
  14. The first mention, on the Grid Status Page, was 8 minutes before the Restarts began. The Lindens obviously have a cunning plan.
×
×
  • Create New...