51+ hours on T34 and still chugging. I /am/ noticing that the Transmission web page (which I tend to leave up on one computer at home all the time... I /know/....) has timed out a few times overnight, but all the clients, including my Time Machine backups, media PC, etc have all been solid.
I guess I'll feel better once I get past the magic 72 hour mark that plagued the last two builds... but I'm hopeful!
The T34 edition of the 4.2.20 firmware has not become publicly available yet. It has been a controlled release by the Jedi council. I am sure that if it becomes one of the more prominent fixes; we will see it on Chirpa's main posting for 4.2.20.
Well, just had a strangest meltdown on my home network. It had all the appearance of a DOS, but some things actually kept working. I rebooted the lot and it seems happier now.
As for the ReadyNAS, it wasn't pinging or responding on the network but it did cleanly shutdown from the FP. So I'm not counting this as a recurrence, as more than just the NAS were affected. 😞
No recurrence of issue now in past 71 hours. I am noticing occasional packet drops by continuous ping. In one hour today it reported 2.5% packet loss. This is from a Mac connected via 1GbE on same switch. But I haven't observed any impact to actual usage. Seems like I shouldn't be getting that kind of loss (NAS CPU is 65%+ idle) and I/O is very low.
When users (you) are using (T## beta releases) are you backed up to another NAS? or confident you can always revert to a stable release (in this case 4.2.19)
Also what does it take for a T## to go gold (or be pushed out as a stable release)?
When users (you) are using (T## beta releases) are you backed up to another NAS? or confident you can always revert to a stable release (in this case 4.2.19)
Also what does it take for a T## to go gold (or be pushed out as a stable release)?
You'd probably get better responses by starting a new thread rather than piggy-backing.
Backup policies shouldn't vary depending upon whether someone is participating in a beta, as a general rule. If you are production mission-critical production, you probably won't be doing beta in that mode. If your NAS isn't hypercritical, then some downtime is acceptable and beta may be an option. It's up to the individual to decide the risk/benefit.
Downgrading to T32 to sanity check that problem there still persists.
One thing I'm noticing is that the Dropbox addon is very sensitive to OS changes. I've had to reinstall it each time just in order to get it to even start up. For reference, version is 1.2.49-rnx86-0.2.25. I'll follow that up separately as well, but wanted to note it here just in case it turns up somehow relevant.
Well, this is interesting... where I had been seeing 1.0-2.5% packet loss on simple ping within LAN on T34, I'm seeing 0.1% packet loss on T32. Only about 8 hours in, so unsure whether I will again experience the hang -- that was within 72 hours on the last couple of releases. I just found the difference in packet loss (with nominal to low traffic/activity) very interesting, given that the change between them had to do solely with the network driver.
Had another recurrence of non-response, but again it seems like all devices were DOS'ed with a packet storm. I suspect this is coming from my DSL router/bridge (UConnect POS) and storm didn't stop until that was rebooted. Throughout, the NAS stayed responsive at FP, so the behavior was not consistent with the other hang scenarios I reported.
OK. Just had a bonefide hang on 4.2.20 [T39]. Was still seeing ping response, but all protocols (including top running over ssh) hung completely. The output from top at the time it stopped responding was:
Had another packet storm tonight. This time I restarted just one component of my network and that restored to normal operation. Powerline module -- HDX111. I have three in use and a fourth as spare. I think I may need to try and swap in the spare to see whether this will help alleviate this particular symptom. Always fun tracking down an unrelated issue when also experiencing real beta bugs. 😉 :nashammer:
Spare HDX111 swapped in and, just for good measure, I reset all three to default settings and enabled security (+rotating net ID and encryption key). Since I only had to reset ONE of the three to clear the storm condition, I've replaced that one with my spare. We shall see if it helped. 😄 :naskiller:
Better to use wired ethernet than ethernet over power if at all possible. Using ethernet over power can be hit and miss. It may work well or it may not depending on a variety of factors including what the electrical wiring is like.
Wonder if any of the other affected users are also using Powerline (or similar) adapters?
Well, I'd say that after several years (two at the present location) they've generally proved themselves. 😉 the only real change in this environment he been 4.2.20. Under 4.2.17 and 4.2.19 this symptom never occurred. Based on other communication, I understand that this behavior has been observed with HDX devices in the past, but they weren't able to call this as a device failure or driver incompatibility. Some other troubleshooting scenarios have been proposed. But for now we'll see what happens with a new unit in place.
The good news is that this behavior is quite discernible from the NAS hang issue, which is really the focus here... And /is/ still happening on T39.
