Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Amigaz on August 18, 2006, 07:05:52 PM
-
Have tried a big bunch of ntp timesync servers with Genesis but none has worked.
Anyone know a site which hosts a list of working servers or a server here in Europe that works with Genesis?
My coin battery in my A4000 is kaputt and I'm too lazy to dismantle my whole tower to replace so the Genesis solution would be sweet :-D
Have tried Facts from Aminet but Genesis is too slow to startup from WBStartup so Facts crashes because it needs a running TCP/IP stack
-
You can start genesis from your S:User-Startup - just put two rows: "Run <>NIL: AmiTCP:GenesisSomething...." and then "WaitForPort AMITCP". You also have to set some options in Genesis first to autoonline the interface you use and not to popup the GUI.
You can also in the Genesis preferences set to execute stuff when it goes online - for example Facts. Facts doesn't seem like a very good program though, as it crashes with no TCP/IP-stack available.
/Patrik
-
Sorry to jump on your thread AMIGAZ but I would also like to know if anyone knows a working daylight time server for Genesis in Europe as I have tried a few times to get it working with those listed on many sites on the net.
/Tim
-
I use NTPSYNC from Aminet. When I connect to the internet, I have this small script automatically run:
*********************************
IF "$TIMEZONE" EQ "-0400"
set flag "-d-240"
ELSE
set flag " "
ENDIF
ntpsync -c $flag time-b.nist.gov
unset flag
*********************************
It gets the current time and adjusts for my timezone and possible DST. I am also running SetDST which takes care of the Daylight Savings Time part. I don't remember for sure, but I believe SetDST creates the TIMEZONE environment variable.
Anyway, to answer your main question, time-b.nist.gov is a working time server.
Lamar
-
patrik wrote:
You can start genesis from your S:User-Startup - just put two rows: "Run <>NIL: AmiTCP:GenesisSomething...." and then "WaitForPort AMITCP". You also have to set some options in Genesis first to autoonline the interface you use and not to popup the GUI.
You can also in the Genesis preferences set to execute stuff when it goes online - for example Facts. Facts doesn't seem like a very good program though, as it crashes with no TCP/IP-stack available.
/Patrik
Thanks Patrik, you saved my day once again :-)
Now I can start Geneis(AmiTCP) quite early in my user-startup
Facts still crash though, have a seperate thread about it in a few secs
Edit: I was wrong, didn´t notice I was browsning cahed sites, lol
Have to work on my user-startup again :P
-
@AMIGAZ:
It has to be after the AmiTCP: assign etc, which the Genesis installer puts in the User-Startup :-D. Other that and the autoonline interface part, I don't know what can go wrong really.
/Patrik
-
patrik wrote:
@AMIGAZ:
It has to be after the AmiTCP: assign etc, which the Genesis installer puts in the User-Startup :-D. Other that and the autoonline interface part, I don't know what can go wrong really.
/Patrik
Lol, anything can go wrong here...remember, I'm a boat engine mechanic :lol:
Anyway, I had this in my user-startup (after the AMITcp assign)
Run <>NIL: Workbench:Internet/Genesis/Genesis
WaitForPort AMITCP
-
AMIGAZ wrote:
Have tried a big bunch of ntp timesync servers with Genesis but none has worked.
im using 129.240.12.4 with genesis, works fine
-
Chain wrote:
AMIGAZ wrote:
Have tried a big bunch of ntp timesync servers with Genesis but none has worked.
im using 129.240.12.4 with genesis, works fine
Thanks, will try it since the WAIT command didn't work with my script.
Genesis still waits to start AmiTCP even though my script is an online event :evil:
Only prob now...will I get Czech time with your recommended server?
:lol:
-
Try cz.pool.ntp.org or check out the lists at http://www.ntp.org
NTP servers all give out UTC time, so provided everything is configured correctly for your location, it shouldn't matter which server you use - although a local one is better.
I don't know whether you saw it in the other thread, but the crashing problem with Facts is not due to the TCP/IP stack being inactive, but a bug in Installer which (non-visibly) corrupts one of the tooltypes when it updates it. If you blank them all out and restart/reconfigure Facts the crash should no longer occur.
Chris
-
@Chain
The server adress worked, thanks ;)