Category: computers

In setting up NTP on nuxx.net I ran into a bit of a problem: time wouldn’t sync. My configuration was fairly simple, following the information on support.ntp.org for using the pool of North American servers, blocking external access, but allowing ntpq (et al) to work from localhost:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

driftfile /var/db/ntp.drift

restrict default ignore
restrict 127.0.0.1

However, it seemed that no matter what I tried (disabling the firewall, adding exceptions for TCP/UDP 123, changing order of the restrict statements, etc) the box wasn’t able to contact its peers:

c0nsumer@banstyle:~> ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 217.160.254.116 .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 209.132.176.4   .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 209.40.97.141   .INIT.          16 u    -   64    0    0.000    0.000 4000.00
 216.14.98.234   .INIT.          16 u    -   64    0    0.000    0.000 4000.00

After some more digging I found that the restrict default ignore option, which is widely recommended to keep external folks from connecting to your ntpd, prevents synchronization from happening, even with the exception for localhost.

Having realized that, my ntp.conf is now just the basic config for the NA servers and the drift file, and it all works great:

server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org

driftfile /var/db/ntp.drift

Yep, it’s syncing just fine:

c0nsumer@banstyle:~> ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*217.160.254.116 18.26.4.105      2 u  200  256   17   37.192    4.619   1.461
 209.132.176.4   66.187.233.4     2 u  201  256   17  101.819   21.118   9.529
 209.40.97.141   192.5.41.40      2 u  197  256   17   38.565  -31.122  21.081
 216.14.98.234   216.218.254.202  2 u  200  256   17   18.731    3.940   4.848

c0nsumer@banstyle:~> ntptrace
localhost: stratum 3, offset 0.004619, root distance 0.043540
server.donkeyfly.com: stratum 2, offset -0.000686, root distance 0.006361
bonehed.lcs.mit.edu: stratum 1, offset 0.000018, root distance 0.000000, refid 'CDMA'

Now I just let pf restrict access to NTP. That works just fine.

Leave a Comment

That’s it. rowla.nuxx.net has been turned off, and I’m slated to pick it up tomorrow sometime around lunch. Everything has been moved over and seems to be working great. So, if I host your stuff on nuxx.net and you are having a problem, please let me know so that it may be corrected.

Leave a Comment

Yesterday I ordered a pair of Seagate Barracuda ES.2 ST3500320NS disks to replace the two which failed on Tuesday. Today I called Newegg about my RMA for the old ones and the old controller and was able to get the 15% restocking fee waived for both the controller and drives. Hopefully the drives will arrive tomorrow and I can dump | restore the OS and such, then start Breakin running so that it can thrash the drives for a few days.

Speaking of Breakin, I disconnected the disks from the machine (but left them mostly fitted in the case as to not disrupt airflow) and started Breakin running this morning before I left for work. When I arrived home it was still running, unlike last week when it regularly failed with MCEs. This is good, as I had been unable to get it to run for this long before.

Leave a Comment

When I got home I started running SeaTools, Seagate’s disk diagnostics utility for Windows, on the ad4 which had begun failing earlier. It reported back that it, and the other hard drive, were just fine. However, when booting into FreeBSD after using them I found that both drives were now indicating that Seek_Error_Rate was past threshold. The OS booted very slow, then kicked ad6 out of the mirror set.

I tried connecting the drives to another, standalone SATA controller (some plain old Maxtor bundle-in one) with new SATA cables and same problem.

So, I’m not sure what to do. Here’s every issue I’ve had with the new server and its resolution:

Issue: Server locking up hard, unexpectedly. MCEs on console.
Resolution: Ensure that only matched RAM is used and that all RAM tests good during burn-in.

Issue: Slow performance / absurd latency while using 3ware disk controller.
Resolution: Identified GIANT-LOCK on driver, moved to using software mirroring.

Issue: One of the original two Western Digital disks used, which were part of a gmirror set, has started giving block errors.
Resolution: Replace disks with brand new Seagate pair.

Issue: Both of the new Seagate drives began failing with excessive Seek_Error_Rate within a few hours of each other after extensive burn in.
Resolution: Unsure.

I can’t help but wonder if one of the Seagates beginning to fail was contributing to the latency observed with the 3ware controller, but as neither was throwing SMART errors at the time, so I discount this.

My current thought is that I should order a pair of server-grade disks, burn them in as before (~50 hours of constant activity), copy the data to them, then see if things will keep working. The failed disks and the unwanted 3ware controller will go back to Newegg, and hopefully things will work right.

I don’t know what other option I have besides scrapping the whole idea of moving servers, but I really rather not do that. If anyone else has any ideas, I’d love to hear them…

Leave a Comment