NTP Sync Problem - NTP

This is a discussion on NTP Sync Problem - NTP ; I'm using Netopia routers on Covad (model 4622 on T1 and 4652 on DSL). They have built-in NTP clock syncronization with two pre-programmed servers. Although the routers work fine, I have never been able to get the sync function working. ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: NTP Sync Problem

  1. NTP Sync Problem

    I'm using Netopia routers on Covad (model 4622 on T1 and 4652 on DSL). They have built-in NTP clock syncronization with two pre-programmed servers. Although the routers work fine, I have never been able to get the sync function working. Left to themselves, they each gain 8 minutes per day so it would be nice to be able to use the sync feature. I know that UDP port 123 should be open in both directions and as a test I turned off the firewall completely. The device event log gives this error message "NTP: cannot SEND packet to server " every 3 minutes, alternating between the primary and secondary NTP servers. Besides the two pre-set servers (204.152.184.72 and 18.72.0.3) I've tried several public servers from the NIST list. BTW, I have no problem syncing computers on the same local network using a Windows-based NIST time client. Only the router itself won't sync and gives that error message.

  2. Re: NTP Sync Problem

    Ron C. wrote:
    > I'm using Netopia routers on Covad (model 4622 on T1 and 4652 on DSL). They have built-in NTP clock syncronization with two pre-programmed servers. Although the routers work fine, I have never been able to get the sync function working. Left to themselves, they each gain 8 minutes per day so it would be nice to be able to use the sync feature. I know that UDP port 123 should be open in both directions and as a test I turned off the firewall completely. The device event log gives this error message "NTP: cannot SEND packet to server " every 3 minutes, alternating between the primary and secondary NTP servers. Besides the two pre-set servers (204.152.184.72 and 18.72.0.3) I've tried several public servers from the NIST list. BTW, I have no problem syncing computers on the same local network using a Windows-based NIST time client. Only the router itself won't sync and gives that error message.


    I don't think that there is any hope of getting those routers to
    synchronize with NTP. NTP generally does not cope with clock frequency
    errors in excess of 500 parts per million or about 43 seconds per day.
    (This is the maximum rate at which most kernels can (or will) slew the
    system clock.)

    Talk to the manufacturer about repair under warranty (if they are still
    under warranty). If not try a better vendor! Cisco Systems sells top
    quality stuff! At top prices, of course! :-)


  3. Re: NTP Sync Problem

    If I set the clock to the correct time manually and then turn on the sync, I don't see how either the NTP server or the client can predict how fast the clock will drift if not adjusted. Thus while it's true that 500 ppm = 43.2 sec/day, I doubt if these machines are smart enough to predict the future. Yet as soon as I turn on the sync, I get the logged message "NTP: cannot SEND packet..." with the word "send" capitalized in the log.

    I guess I'm wondering if anyone has any idea why these relatively new (and otherwise flawless) routers would produce such a message in the first place. Is it possibe that a received sync signal is like an ACK response and if it's missing the router produces the obscure "cannot SEND" message? Is it possible that Covad blocks UDP port 123 requests unless they're directed to some special non-public server?

    I'm having visions of all the Covad customer-premises routers all over the country, sending NTP requests every 3 minutes to one or the other of the two default servers. I've successfully sent ICMP requests to the servers both from my network and from the router's built-in ping utility. I suspect I'm doing something wrong, just can't imagine what.

    "Richard B. gilbert" wrote in message news:45EB6E0D.8000604@comcast.net...
    > Ron C. wrote:
    > > I'm using Netopia routers on Covad (model 4622 on T1 and 4652 on DSL). They have built-in NTP clock syncronization with two pre-programmed servers. Although the routers work fine, I have never been able to get the sync function working. Left to themselves, they each gain 8 minutes per day so it would be nice to be able to use the sync feature. I know that UDP port 123 should be open in both directions and as a test I turned off the firewall completely. The device event log gives this error message "NTP: cannot SEND packet to server " every 3 minutes, alternating between the primary and secondary NTP servers. Besides the two pre-set servers (204.152.184.72 and 18.72.0.3) I've tried several public servers from the NIST list. BTW, I have no problem syncing computers on the same local network using a Windows-based NIST time client. Only the router itself won't sync and gives that error message.

    >
    > I don't think that there is any hope of getting those routers to
    > synchronize with NTP. NTP generally does not cope with clock frequency
    > errors in excess of 500 parts per million or about 43 seconds per day.
    > (This is the maximum rate at which most kernels can (or will) slew the
    > system clock.)
    >
    > Talk to the manufacturer about repair under warranty (if they are still
    > under warranty). If not try a better vendor! Cisco Systems sells top
    > quality stuff! At top prices, of course! :-)
    >


  4. Re: NTP Sync Problem

    If I set the clock to the correct time manually and then turn on the sync, I don't see how either the NTP server or the client can predict how fast the clock will drift if not adjusted. Thus while it's true that 500 ppm = 43.2 sec/day, I doubt if these machines are smart enough to predict the future. Yet as soon as I turn on the sync, I get the logged message "NTP: cannot SEND packet..." with the word "send" capitalized in the log.

    I guess I'm wondering if anyone has any idea why these relatively new (and otherwise flawless) routers would produce such a message in the first place. Is it possibe that a received sync signal is like an ACK response and if it's missing the router produces the obscure "cannot SEND" message? Is it possible that Covad blocks UDP port 123 requests unless they're directed to some special non-public server?

    I'm having visions of all the Covad customer-premises routers all over the country, sending NTP requests every 3 minutes to one or the other of the two default servers. I've successfully sent ICMP requests to the servers both from my network and from the router's built-in ping utility. I suspect I'm doing something wrong, just can't imagine what.

    "Richard B. gilbert" wrote in message news:45EB6E0D.8000604@comcast.net...
    > Ron C. wrote:
    > > I'm using Netopia routers on Covad (model 4622 on T1 and 4652 on DSL). They have built-in NTP clock syncronization with two pre-programmed servers. Although the routers work fine, I have never been able to get the sync function working. Left to themselves, they each gain 8 minutes per day so it would be nice to be able to use the sync feature. I know that UDP port 123 should be open in both directions and as a test I turned off the firewall completely. The device event log gives this error message "NTP: cannot SEND packet to server " every 3 minutes, alternating between the primary and secondary NTP servers. Besides the two pre-set servers (204.152.184.72 and 18.72.0.3) I've tried several public servers from the NIST list. BTW, I have no problem syncing computers on the same local network using a Windows-based NIST time client. Only the router itself won't sync and gives that error message.

    >
    > I don't think that there is any hope of getting those routers to
    > synchronize with NTP. NTP generally does not cope with clock frequency
    > errors in excess of 500 parts per million or about 43 seconds per day.
    > (This is the maximum rate at which most kernels can (or will) slew the
    > system clock.)
    >
    > Talk to the manufacturer about repair under warranty (if they are still
    > under warranty). If not try a better vendor! Cisco Systems sells top
    > quality stuff! At top prices, of course! :-)
    >


  5. Re: NTP Sync Problem

    Ron C. wrote:
    > If I set the clock to the correct time manually and then turn on the
    > sync, I don't see how either the NTP server or the client can predict
    > how fast the clock will drift if not adjusted. Thus while it's true
    > that 500 ppm = 43.2 sec/day, I doubt if these machines are smart
    > enough to predict the future. Yet as soon as I turn on the sync, I
    > get the logged message "NTP: cannot SEND packet..." with the word
    > "send" capitalized in the log.
    >


    These messages aren't from the NTP reference implementation.

    > I guess I'm wondering if anyone has any idea why these relatively new
    > (and otherwise flawless) routers would produce such a message in the
    > first place. Is it possibe that a received sync signal is like an
    > ACK response and if it's missing the router produces the obscure
    > "cannot SEND" message? Is it possible that Covad blocks UDP port 123
    > requests unless they're directed to some special non-public server?
    >


    Some firewall is blocking outgoing packets from the look of it.

    > I'm having visions of all the Covad customer-premises routers all
    > over the country, sending NTP requests every 3 minutes to one or the
    > other of the two default servers. I've successfully sent ICMP
    > requests to the servers both from my network and from the router's
    > built-in ping utility. I suspect I'm doing something wrong, just
    > can't imagine what.
    >


    Contact Covad and ask them. We can't help you here except to advise you
    to notify them that they need permission from the providers of NTP time
    before they embed addresses in their equipment.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: NTP Sync Problem

    On Mar 5, 2:15 am, "Ron C." wrote:
    > I'm having visions of all the Covad customer-premises routers all over
    > the country, sending NTP requests every 3 minutes to one or the other
    > of the two default servers. I've successfully sent ICMP requests to the
    > servers both from my network and from the router's built-in ping utility.


    Well, those two hosts are clock.isc.org and bitsy.mit.edu. Assuming
    Covad did not get permission to use those time servers, it could very
    well be that MIT and ISC are blocking UDP port 123 requests from
    Cogent's networks in retaliation. Can you try to use an NTP-specific
    diagnostic from the same Covad connection, rather than just ping? If
    you have a windows machine, it would be something like:
    w32tm /monitor /computers:204.152.184.72,18.72.0.3
    If that works, then the problem is definitely in the device and not in
    the network somewhere.

    Regards,
    Ryan


  7. Re: NTP Sync Problem


    "Ryan Malayter" wrote in message news:1173108501.797067.269830@30g2000cwc.googlegro ups.com...

    >
    > Well, those two hosts are clock.isc.org and bitsy.mit.edu. Assuming
    > Covad did not get permission to use those time servers, it could very
    > well be that MIT and ISC are blocking UDP port 123 requests from
    > Cogent's networks in retaliation. Can you try to use an NTP-specific
    > diagnostic from the same Covad connection, rather than just ping? If
    > you have a windows machine, it would be something like:
    > w32tm /monitor /computers:204.152.184.72,18.72.0.3
    > If that works, then the problem is definitely in the device and not in
    > the network somewhere.
    >
    > Regards,
    > Ryan


    I went to ntp.isc.org web site and verified that clock.isc.org is a stratum 1 server with open access and no notification required. (An open access time server may be used without restrictions by any client in any location.) Unfortunately, I can't run w32tm since I'm currently running Windows 98. It does have a program called "net time" which appears to recognize only Windows computers on the local network. (The syntax allows you to specify either a Windows computer on your workgroup or on another workgroup.) Guess I'll have to call Covad or Netopia tech support after all. Thanks for your help, I've learned a lot.

  8. Re: NTP Sync Problem

    Ron,

    Ron C. wrote:
    > "Ryan Malayter" wrote in message
    > news:1173108501.797067.269830@30g2000cwc.googlegro ups.com...

    [...]
    > Windows 98. It does have a program called "net time" which appears to
    > recognize only Windows computers on the local network.


    Right, "net time" doesn't use the NTP protocol but a MS proprietary protocol
    based on NETBIOS.

    That's why you can't use "net time" to get the time from a NTP server,
    unless that NTP server machine runs Windows or Samba.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: NTP Sync Problem

    Ron C. wrote:
    >
    > I went to ntp.isc.org web site and verified that clock.isc.org is a
    > stratum 1 server with open access and no notification required. (An
    > open access time server may be used without restrictions by any
    > client in any location.)


    Really? Did you just ignore this part?:
    *ServiceArea: BARRnet, Alternet-west, CIX-west
    See:
    http://ntp.isc.org/bin/view/Servers/ClockIscOrg

    *The geographic and/or network area your TimeServer is intended to serve.

    Open Access does NOT mean that you can embed it in any device that you
    want to sell.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  10. Re: NTP Sync Problem


    "Danny Mayer" wrote in message news:45ED67AB.7060203@ntp.isc.org...
    > Ron C. wrote:
    > >
    > > I went to ntp.isc.org web site and verified that clock.isc.org is a
    > > stratum 1 server with open access and no notification required. (An
    > > open access time server may be used without restrictions by any
    > > client in any location.)

    >
    > Really? Did you just ignore this part?:
    > *ServiceArea: BARRnet, Alternet-west, CIX-west
    > See:
    > http://ntp.isc.org/bin/view/Servers/ClockIscOrg
    >
    > *The geographic and/or network area your TimeServer is intended to serve.
    >
    > Open Access does NOT mean that you can embed it in any device that you
    > want to sell.


    If you click on the word "OpenAccess" under access policy on the site you included above, you're taken to a page that gives the definition I used. You are right, there are hundreds of time servers all over the world and perhaps I should use a more appropriate one. However my problem is that none of the servers I've tried work (including 3 California based servers provided by NIST for new users).

    Today I spoke with Netopia Tech Support and they say that the default servers work fine for them but they are not using Covad. They told me I should contact Covad since it appears Covad is causing the problem (the same sync problem happens on my 2 different routers on 2 different circuits, a DSL and aT1). I just called Covad and the person I spoke to said she was told this is normal and that they normally just set the time manually w/o using syncing. I asked her to take a trouble report anyway, saying "you don't have to fix it; just give me an explanation of what is going on."



  11. Re: NTP Sync Problem

    On Mar 6, 8:50 pm, "Ron C." wrote:
    > Today I spoke with Netopia Tech Support and they say that the default
    > servers work fine for them but they are not using Covad. They told me
    > I should contact Covad since it appears Covad is causing the problem
    > (the same sync problem happens on my 2 different routers on 2 different
    > circuits, a DSL and aT1). I just called Covad and the person I spoke to
    > said she was told this is normal and that they normally just set the time
    > manually w/o using syncing. I asked her to take a trouble report anyway,
    > saying "you don't have to fix it; just give me an explanation of what is
    > going on."


    Have you tried using us.pool.ntp.org servers instead? What about
    ntp.level3.net? (Covad appears to use Level 3 for backbone transit). I
    can't imagine Covad is blocking all UDP port 123 traffic, unless
    they're trying to stop P2P clients from using that.


  12. Re: NTP Sync Problem


    "Ryan Malayter" wrote in message news:1173281502.368065.80960@p10g2000cwp.googlegro ups.com...

    >
    > Have you tried using us.pool.ntp.org servers instead? What about
    > ntp.level3.net? (Covad appears to use Level 3 for backbone transit). I
    > can't imagine Covad is blocking all UDP port 123 traffic, unless
    > they're trying to stop P2P clients from using that.


    Thanks for the suggestion. I tried them also but the problem is the same. However I did manage to get a semi-understandable explanation from Covad as to what is going on. It has to do with the type of service I have (multiple routable IP addresses as opposed to a single IP using NAT). Apparently T1 and DSL routers have 2 IPs: The WAN IP and the LAN IP. The LAN IP is like another routable host on my network. However Covad makes the WAN IP private (non-routable) with the local end programmed as 0.0.0.0 and the remote as 127.0.0.2. Apparently Netopia uses the WAN IP for NTP and the router knows that it makes no sense to try to use NTP with a non-routable IP, so it logs the "cannot send" error message.

    Of course, this bring to mind even more questions like 1) Why do routers need 2 IPs? 2) Why doesn't Netopia use the routable LAN IP for NTP or a least let you specify which one to use? 3) Why can't I donate one of my routable network IPs for use as the WAN IP? 4) Do all the routers it the world, providing the same type of service, have this inablity to use NTP? 5) How common is it for router clocks to drift by 8 minutes per day (as both of mine do).


  13. Re: NTP Sync Problem

    In article <33448$45efe4e1$42865632$32620@msgid.meganewsserver s.com>
    "Ron C." writes:
    >
    >Thanks for the suggestion. I tried them also but the problem is the
    >same. However I did manage to get a semi-understandable explanation
    >from Covad as to what is going on. It has to do with the type of
    >service I have (multiple routable IP addresses as opposed to a single IP
    >using NAT). Apparently T1 and DSL routers have 2 IPs: The WAN IP and
    >the LAN IP. The LAN IP is like another routable host on my network.
    >However Covad makes the WAN IP private (non-routable) with the local end
    >programmed as 0.0.0.0 and the remote as 127.0.0.2. Apparently Netopia
    >uses the WAN IP for NTP and the router knows that it makes no sense to
    >try to use NTP with a non-routable IP, so it logs the "cannot send"
    >error message.


    I'm not sure I followed all that, but if the router has its WAN
    interface "configured" with 0.0.0.0, it's no surprise that it refuses to
    originate traffic in that direction. Nothing NTP-specific, nor even
    necessarily knowledge about what is "routable", but sending out IP
    packets with source address 0.0.0.0 is just Plain Wrong (unless you're
    booting and need to speak DHCP/BOOTP before you can get your address).

    But I believe you said that it worked fine to do NTP requests from
    inside your network (and I would expect that, as long as the router
    doesn't try to NAT them to 0.0.0.0:-). Couldn't you just set up an NTP
    server there, and point the router at *that*? This would also have the
    advantage that if the router goes berserk and starts spewing requests
    continously, only you will suffer.:-)

    --Per Hedeland
    per@hedeland.org

  14. Re: NTP Sync Problem


    "Per Hedeland" wrote in message news:esq7cq$1qtc$3@hedeland.org...
    > In article <33448$45efe4e1$42865632$32620@msgid.meganewsserver s.com>
    > "Ron C." writes:
    > >However Covad makes the WAN IP private (non-routable) with the local end
    > >programmed as 0.0.0.0 and the remote as 127.0.0.2. Apparently Netopia
    > >uses the WAN IP for NTP and the router knows that it makes no sense to
    > >try to use NTP with a non-routable IP, so it logs the "cannot send"
    > >error message.

    >
    > I'm not sure I followed all that, but if the router has its WAN
    > interface "configured" with 0.0.0.0, it's no surprise that it refuses to
    > originate traffic in that direction. Nothing NTP-specific, nor even
    > necessarily knowledge about what is "routable", but sending out IP
    > packets with source address 0.0.0.0 is just Plain Wrong (unless you're
    > booting and need to speak DHCP/BOOTP before you can get your address).
    >
    > But I believe you said that it worked fine to do NTP requests from
    > inside your network (and I would expect that, as long as the router
    > doesn't try to NAT them to 0.0.0.0:-). Couldn't you just set up an NTP
    > server there, and point the router at *that*? This would also have the
    > advantage that if the router goes berserk and starts spewing requests
    > continously, only you will suffer.:-)
    >
    > --Per Hedeland
    > per@hedeland.org


    The problem causing the "cannot SEND" error message seems to be the originating IP rather than the destination IP. The Netopia router uses the WAN IP as the originating source. In order to conserve their IP address space Covad causes this WAN IP to be of the private type (172.19.x.x). [BTW this number is NOT one of the WAN numbers entered into the router during setup which are 0.0.0.0 and 127.0.0.2. It seems to be aquired by the router when the connection with Covad is authenticated.] In any case, Covad tech support said that the router tries to use this "private" IP as a source and that's why it fails. I think the NTP program in the router stops in its tracks when it sees the private IP and produces the "cannot SEND" error message instead of sending the NTP request. It's probably not going berserk, it's just designed to send NTP requests FROM a routable public WAN IP, and stops because it doesn't have one. In my case it's the LAN side that has routable IPs since I'm paying extra for a block of 16 IP addresses, so that I can have internet servers. (Some of these are part of a DHCP pool programmed in the router for non-servers on my network.) NAT is not used. I believe that if I were using NAT instead, the single routable IP would be on the WAN while the LAN addresses would be private and then the router would be able to send NTP requests to set its own clock.

  15. Re: NTP Sync Problem

    In article
    "Ron C." writes:
    >
    >"Per Hedeland" wrote in message
    >news:esq7cq$1qtc$3@hedeland.org...
    >>
    >> But I believe you said that it worked fine to do NTP requests from
    >> inside your network (and I would expect that, as long as the router
    >> doesn't try to NAT them to 0.0.0.0:-). Couldn't you just set up an NTP
    >> server there, and point the router at *that*? This would also have the
    >> advantage that if the router goes berserk and starts spewing requests
    >> continously, only you will suffer.:-)


    >The problem causing the "cannot SEND" error message seems to be the
    >originating IP rather than the destination IP.


    Yes, I understood that much:-) - but most devices use the address
    configured on the interface where the packets go out as source address.
    Thus there is a significant probability that it will be able to send
    through the internal interface - I believe you said that the internal
    interface had a real address.

    > The Netopia router uses
    >the WAN IP as the originating source.


    But you've only seen this on packets going out the WAN interface, right?
    Or rather, seen that packets fail to go out there...

    > I
    >think the NTP program in the router stops in its tracks when it sees the
    >private IP and produces the "cannot SEND" error message instead of
    >sending the NTP request.


    Extremely unlikely that they would have put such functionality into
    their NTP implementation I think, it's probably rather the TCP/IP stack,
    or an internal firewall, that refuses to send the message with that
    "bogus" source address (or 0.0.0.0).

    > It's probably not going berserk


    Not yet.:-)

    --Per Hedeland
    per@hedeland.org

  16. Re: NTP Sync Problem

    My semi-explanation of what is going on is based mainly on the Covad tech-support statement that the private IP (172.19.x.x) which Covad imposes on the WAN side of the router for my type of circuit (multiple routable IPs on the LAN not NAT) coupled with Netopia's default, firmware implemented, and inflexible programming causes the built-in NTP to fail. Hopefully, someone at Netopia will see this thread and fix their firmware in a future release so that the built-in NTP can be made to work with Covad's IP setup for this case.

    I did try pointing the built-in NTP at one of the hosts on my network and recieved the same "cannot SEND" log message. However, I don't have an NTP server on my Win98 network. If you know of a program for Windows 98 send me the url and I'll try it. But I doubt it will make any difference, based on Covad's statement.

  17. Re: NTP Sync Problem

    In article
    "Ron C." writes:
    >
    >I did try pointing the built-in NTP at one of the hosts on my network
    >and recieved the same "cannot SEND" log message. However, I don't have
    >an NTP server on my Win98 network. If you know of a program for Windows
    >98 send me the url and I'll try it. But I doubt it will make any
    >difference, based on Covad's statement.


    I agree (but based on your getting a local failure on the box rather
    than based on what they said:-) - in that case it's not likely that
    actually having a server will make any difference. But it was worth a
    try...

    --Per Hedeland
    per@hedeland.org

  18. Re: NTP Sync Problem

    Ron C. wrote:
    > My semi-explanation of what is going on is based mainly on the Covad
    >tech-support statement that the private IP (172.19.x.x) which Covad

    imposes
    >on the WAN side of the router for my type of circuit (multiple

    routable IPs
    >on the LAN not NAT) coupled with Netopia's default, firmware implemented,
    >and inflexible programming causes the built-in NTP to fail. Hopefully,
    >someone at Netopia will see this thread and fix their firmware in a future
    >release so that the built-in NTP can be made to work with Covad's IP setup
    >for this case.
    >
    > I did try pointing the built-in NTP at one of the hosts on my network and
    >recieved the same "cannot SEND" log message. However, I don't have an NTP
    >server on my Win98 network. If you know of a program for Windows 98

    send me
    >the url and I'll try it. But I doubt it will make any difference, based
    >on Covad's statement.


    http://ntp.isc.org/bin/view/Main/Ext...rosoft_Windows

    It's not listed as being supported on W98. It may or may not work. Why
    in the world are you still using W98? It was obsoleted seven years ago
    by W2K which offers much better reliability and W2K has since been
    obsoleted by W/XP which is still better. Ntpd is available for both W2K
    and W/XP.


  19. Re: NTP Sync Problem


    "Per Hedeland" wrote in message news:esu9ve$16nj$1@hedeland.org...
    > In article


    > I agree (but based on your getting a local failure on the box rather
    > than based on what they said:-)


    Because of the smily face, I take it you're not disagreeing with tech-support, just commenting that you're usually skeptical of them. So am I. The first person I spoke to said that they noticed a lot of clocks were off, by decades in fact. But they were told only to reset them manually.

  20. Re: NTP Sync Problem


    "Richard B. gilbert" wrote in message news:45F2BCCC.3050806@comcast.net...
    >Why
    > in the world are you still using W98?


    My 1996 $6000 Laptop is only 133MHz. I've used trial versions of Windows XP and Windows Server 2003 on it but they're way too slow scrolling through documents; even Win98 slowed things down noticibly compared to Win95; also the sound driver didn't work and Toshiba had no XP update.

    >It was obsoleted seven years ago


    but supported until last July.

    > by W2K which offers much better reliability


    Win98 works with my hardware and has been reliable enough. As an added bonus, which I'm now spoiled by, the tiny fan broke years ago so it's as quiet as a PDA. This is very important when it's on 24/7.

    >and W2K has since been
    > obsoleted by W/XP which is still better.


    I think you mean more feature-rich if you have the hardware to support it. I've made several visits to CompUSA over the years and marveled at how sluggish the XP machines behave even with 1 GHz processors. When I click on something it's as if the XP machine is saying "aw shucks, you want me to do something...well ok just be patient while I run through several million lines of code to figure out what you want."

    I agree it's about time to upgrade. Applications and web pages have become too complex (and inefficient) for a 133 MHz chip. I'm looking into a 1.5 GHz Vista Ultimate machine from OQO, which is still not powerful enough to run Aero-Glass. If it feels sluggish, well, I still have my Win98 disk! I just hope I don't notice the sound of the fan.



+ Reply to Thread
Page 1 of 2 1 2 LastLast