22 December 2010, 17:45 | #1 |
Registered User
Join Date: Apr 2007
Location: Belgrade
Posts: 567
|
amitcp sync clock
how do you synchronize the clock with builtin amitcp util in bin/ ?
it keeps complaining 'service not started' I have used NTPsync before, but that won't work with amitcp_v3.x |
26 February 2011, 20:15 | #2 |
Registered User
Join Date: Oct 2009
Location: Salem, OR
Posts: 1,767
|
**UPDate:
OK, rdate works. It's on Aminet (Note:rdatetz wasn't as straight forward, so I'd skip that one..) Basically, download rdate and extract it. Copy rdate to AmiTCP:bin I added two variables to my S:User-Startup file (in the AmiTCP section) setenv TZ_TIMESERVER nist1-la.ustiming.org setenv TZ_CHU 8 (The 8 means 8 hours West of Greenwich, there's more info on that in the DOC file) (I got the time server from here: http://tf.nist.gov/tf-cgi/servers.cgi# ) Then I added the command to my AmiTCP:bin/startnet at the end: AmiTCP:bin/rdate And that was it... Now, when I ran it the second time, it took a bit longer and gave me an error, but the error was "time is correct" basically, so it isn't a big deal. But, if you run startnet a lot, you might not want to put rdate into your startnet.. Also, this doesn't appear to have an option to save it to a battery backed RTC, but I don't have a battery backed RTC.. ;-) desiv synclock is a script that looks for specific results from a "daytime" or "time" server, not a NTP server. I only browsed the script and I'm a bit rusty with the other formats. And the pool NTP servers used to hand out those other protocols, but don't anymore... Either the formats have changed or the specific services aren't running anymore. When I ran it against a NIST server, it complained that the information it got and passed to the "DATE" command wasn't valid. NIST is still serving time using DAYTIME, I just checked. But it's not the format expected in the script. There is an "updated" synclock on aminet I just saw that might work... My Amiga scripting is really rusty, but I'll see if I can tweak synclock to recognize what the current NIST servers are reporting if the updated versions don't work. A better solution would be to take the source for ntpdate and recompile it using the AmiTCP3 dev files. NTP is preferred, although more complicated. But I don't know whether or not AmiTCP 3 might be missing some functions used for that, in which case that might be a lot more work... I wouldn't mind taking a crack at that, but I haven't installed a C environment yet. It's on my list of things to get back into on the Amiga.. --- No luck so far with the other synclock on aminet. It's definitely the DAYTIME service it's looking for in the original script, but the original script is ARexx, which I haven't ever really used before.. It's definitely not what it's expecting tho. It was looking for the time as the 4th "word" in the response, but the response I get is: 55618 11-02-26 19:06:31 00 0 0 638.2 UTC(NIST) * And the time is the 3rd word. It didn't fix it by changing that, so the date part is also wrong, but the date part is much more complicated ARexx.. Also, I am noticing that the time is UTC and this script looks to be expecting local time... desiv Last edited by desiv; 27 February 2011 at 05:40. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Clock-Sync after resume from standby.. | tbone | request.UAE Wishlist | 2 | 06 July 2013 23:35 |
amitcp/ip | lambrettadave | support.Hardware | 1 | 21 October 2010 16:42 |
Amitcp | Pentangle | request.Apps | 2 | 07 May 2008 09:03 |
Time sync | mr_0rga5m | project.EAB | 2 | 24 April 2004 10:23 |
V-sync Problem | bigly | support.WinUAE | 6 | 12 September 2002 17:17 |
|
|