"Stephen Gutknecht (SAPDB)" schrieb: > > Hello Joerg, > > You obviously don't work in the same areas I do :) Our serves must be > synced to a known references constantly. > > Windows 2000 on intel hardware does not keep that good time. I notice our > SMP Intel SCB2 motherboard systems (dual Pentium 3 1.26Ghz) drift fast about > 30ms every 20 minutes. The harder the load on the CPU, the more the drift. > > The way we deal with it is to set the clock every 20 minutes ... that way > the changes are not big enough to foul up log times and so forth. We wrote > a custom program that even makes sure the absolute change is never more than > 1/4 of a second (250ms), that way big changes are avoided and can be done > during reboot cycles. Normally the every 20 minute change keeps things in > sync.
Your problem seems to be a Windows problem. I'm running 23 Linux servers across Europe connected trough WAN links ranging from 1Mbit/s to as small as 16kbit/s and they sync time via ntpd against two central servers. Max. offset is around ~25ms, typical offset is ~10ms. I remember a project where we had to sync many servers in a similar environment, and it turned out that the Windows boxes were the difficult ones. Did you try the Windows version of NTP http://www.eecis.udel.edu/~ntp/software/winnt.html . I have not used it but it may be useful. Simon > > I have seen other systems drift slow... each motherboard/CPU combination has > a different behavior. > > We have to connect to outside web servers on a 1/2 second (500ms) accuracy > for one of our business ventures, so it is not an option to let the clock > drift out. > > Think of it this way: What if you have 10 servers running the same > application, logging to a common database, wouldn't it be worse if they all > had different times? PC clocks are not the greatest... Yes, you could let > the database provide the timestamp, but sometimes you are recording the time > from an event that happens before the actual SQL INSERT statement. > > I know there are hardware solutions to this (better clock chips and driver > that references the hardware), but it has just been easier to set the clock > in software. Windows and other operating systems I have worked with have > agents to automate this. > > To answer your questions: > > How do you deal with doubled timed period? That is where sequence number is > combined with time period. In our time-critical application, we can still > tell what comes first - even if the time stamp shows otherwise (rare). > > I fully understand the hibernation issue - but I really doubt too many > people are hibernating their servers. Adjusting the clock is pretty common > practice that I have seen... The time zone change you reference, Windows > practically encourages this. A application solution is to use universal > time, but still... clock corrections do have to be made based on my > experience. > > Regards, > > Stephen > > -----Original Message----- > From: Mensing, Joerg [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 20, 2002 5:24 AM > To: 'Stephen Gutknecht (SAPDB)' > Cc: [EMAIL PROTECTED] > Subject: RE: Problem with hibernate: 7.4 Beta randomly crashing (Windows) > > Hi, > it concerns my that you think about restting time on a server. You can set > your clock into the past, while SAPDB is running you, but only using a time > daemon in differential mode. As SAP customer you are forced to do so or your > R/3 system may crash. > > SAPDB may survive that, but i would stop it anyhow before i would to reset > the time! > > Why? > > What about your applications? How do they handle a 'doubled' time period? If > your application survives daylight saving time changes without logical > problems (if they use local timestamps), it is save but only very small > number of applications do really survive daylight saving time without > logical problems. If you wildly modify your local time you will confuse any > kind of time depending process. Think about make dependency i.e. or cron > jobs... > > ... but the hibernation problem is a differrent thing, since it resets the > internal clock register! On NT you will not influence that internal CPU > register by setting the wall clock. The register used is only counting the > external clock chrystal signal depending on the MHz provided, but has > nothing to do with your wall clock. > > In a good server environment you should try not to play with the time scale. > > CU > jrg > > > -----Original Message----- > > From: Stephen Gutknecht (SAPDB) [mailto:[EMAIL PROTECTED]] > > Sent: Dienstag, 19. November 2002 21:24 > > To: Mensing, Joerg; [EMAIL PROTECTED] > > Subject: RE: Problem with hibernate: 7.4 Beta randomly crashing > > (Windows) > > > > > > Humm... > > > > This concerns me a bit. What happens if the clock is changed > > while SAPDB is > > running? Is there any chance that a clock correction (fast > > clock set back > > 20 seconds every 12 hours) could cause problems? > > > > Stephen > > > > > > -----Original Message----- > > From: Mensing, Joerg [mailto:[EMAIL PROTECTED]] > > Sent: Monday, November 18, 2002 4:52 AM > > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > > Cc: Roedling, Raymond > > Subject: Problem with hibernate: 7.4 Beta randomly crashing (Windows) > > > > > > Hi, > > with turning hibernation on, Raymond was able to reproduce > > the crash. It > > seems to be the hibernate mode then... If hibernation is > > turned on, the CPU > > timer register seems to be spontanously resetted during wakeup. This > > confuses time measurement function, which does not expect to > > have entered > > the dispatcher function after leaving it... > > > > This does not have an effect both on 'PERFCNTR' and 'TICKS' setting of > > HIRES_TIMER_TYPE. So if you decide to allow hibernation of your laptop > > you definitly have to modify the parameter. > > > > CU > > jrg > > > > > > > -----Original Message----- > > > From: Mensing, Joerg > > > Sent: Montag, 18. November 2002 09:34 > > > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] > > > Cc: Roedling, Raymond > > > Subject: RE: 7.4 Beta randomly crashing (Windows) > > > > > > > > > Hi, > > > in 7.4 a new high resolution timing code is used. The method is > > > selectable by parameter "HIRES_TIMER_TYPE" (NT only). Default is > > > 'CPU' which means the code uses the RDTSC instruction to get the > > > actual tick count from an internal CPU register. > > > It seems that this code does not work with your laptop CPU. > > > You should try to set the parameter "HIRES_TIMER_TYPE" to 'PERFCNTR' > > > or 'TICKS' instead. I hope your random crashes will disappear. > > > CU > > > jrg > > > > > > > -----Original Message----- > > > > From: Ray Harrison [mailto:[EMAIL PROTECTED]] > > > > Sent: Samstag, 16. November 2002 00:20 > > > > To: [EMAIL PROTECTED] > > > > Subject: 7.4 Beta randomly crashing (Windows) > > > > > > > > > > > > Hello - > > > > I have downloaded the beta for 7.4 and have it installed on my > > > > laptop - PIII/500mz 384mb ram, Win2K professional, SP3. I'm not > > > > really doing anything with it except for the odd table creation, > > > > etc. Anyway, I have noticed that at random times, I will get > > > > a message about the kernal aborting > > > > and shutting down. I have enclosed the error file from > > > > today's sessions. I also notice the same > > > > thing on my Proliant 6500 - Win 2K Server, 1.5 gig, but have > > > > been using the laptop mostly. It may > > > > that I am not setting everything up correctly of course, but > > > > I assumed that random crashes > > > > (seemingly) aren't a good thing! > > > > > > > > Enclosed, please find the error file and let me know should I need > > > > to provide additional information. > > > > > > > > Warm Regards - > > > > Ray Harrison > > > > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
