Re: [ntp:questions] Network latency questions
Hi all, Thanks for the responses. On Thursday 27 May 2010 15:13:50 Joseph Gwinn wrote: In article 201005271035.46352.fmgrotep...@yahoo.co.uk, Frans Grotepass fmgrotep...@yahoo.co.uk wrote: Hi all, Sorry for abusing my membership to this forum for this question. We are busy with building an embedded application that must retrieve data very fast. Please define very fast in numbers. For example, 95% of responses must be fully received within 1,000 microseconds, and 100% within 10 milliseconds, or the planet will explode. This matches the specs. What does the embedded application do? SMS-routing The choice is to either have the data locally or go to a central server(pool) that contains the data. Well, locally is always faster and more predictable than remotely, so why even consider remotely? The problem is that the remote db is already available and this will mean replicating the remote db locally. The remote db has all the data in memory. The local response time must be so fast that one needs a db solution with all the data in memory, otherwise the disk seek time will kill us. In evaluating the network option, I thought that the people here could possibly help me with the expected network latency for a Gb network via a switch. My gut feeling says that with increased load, the switch will bundle the traffic to the different nodes more and this will result in higher latency. Big switches can have transit latencies of a few tens of microseconds, but there is far more to it than that. And if there is a choke point somewhere, the observed latencey will vary wildly depending on perhaps unrelated traffic and loading, making it appear that the latency varies randomly. The farther the commands and resulting data travel, the more vulnerable one is to these effects. These delays (even with local network) will make the solution impossible. Sorry again for posing the questions here. I know this is a blatant off topic post, but getting the details from the internet is a little more difficult and there are so many people here with the knowledge at hand. Thanks for the help. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On Saturday 03 October 2009 02:58:03 David Hawkins wrote: Hi I'm using a number of XTX form factor AMD Geode LX (500Mhz) cards at work. (Cannot get to news at work, and have left memory stick with details at work ! so apologies for missing info !) They are running Sues Linux from a read only flash drive, all identical clones other than host names and IP addresses. Most of the time ntp runs with no problems and will lock to a local server with less than 5ms offset, and the drift file comes out at between about -20 and -40. But now and again a system will not get a stable lock, and on investigation the drift file is at the maximum of -500. When I first encountered this I assumed it was a hardware problem with the processor card, just a one off, but now have seen this on around 10 systems out of 30 or so I have tested. When a system shows this fault, powering the unit on and off will almost always solve it, the unit synchronising to the server after a couple of hours with a drift file setting of -20 to -40 like the others. I'm more of a hardware engineer than software, but have now run out things to look at to solve this problem. I have considered / done the following * The drift file is stored in the ram drive /dev/shm so always starts at 00.000 when the system is started. * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip has two settings off and on with a -0.5% spread. Have verified with a spectrum analyser that the cards with good lock and bad lock, have the spread spectrum option enabled. * The cards seem to be more lightly to exhibit the problem when they have been turned off for a day or so. * Power saving modes of the processor are enabled, but understand that the timing is done using the counter timer in the Geode companion chip that runs at a constant 14.13MHz regardless of the power state:- also as all running exactly the same code why would some have problems and not others ? Sorry rather random thoughts but I have now run out of things to look at, have you ever seen a problem like this and even better found a solution ? Dave Dave, did you play around with adjtimex? I once had a machine who's internal clock was so horribly skewed that it would never sync. Tweaking the parms with adjtimex made the clock more stable and NTP could suddenly sync. Best regards, Frans ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
