OpenBSD support thread

Website · Post by **Z-Man** » Wed Jan 24, 2007 12:18 am

Ah, it's timer lag. The clock on your client seems to go faster than the clock on the server. The last time I saw this was with someone who had overclocked his motherboard and the timer with it, but that would affect internet games, too. I'll have a closer look tomorrow.

belenus · Post by **belenus** » Wed Jan 24, 2007 7:25 am

Lucifer wrote:It's a poll in the developer's forum. Were you planning on maintaining the openbsd port?

Ahh, yes, of cause. I already posted it on the official OpenBSD ports@ list too, but it can take time until "unimportant" stuff like that gets acknowledged or even looked at...

belenus · Post by **belenus** » Wed Jan 24, 2007 7:28 am

z-man wrote:Ah, it's timer lag. The clock on your client seems to go faster than the clock on the server. The last time I saw this was with someone who had overclocked his motherboard and the timer with it, but that would affect internet games, too. I'll have a closer look tomorrow.

The client machine actually is slightly overclocked... but only the CPU.

Website · Post by **Z-Man** » Wed Jan 24, 2007 11:48 am

It's definitely a real time measurement problem. Either the clock on the server goes slow, or the clock on the client is too fast. It could be possible to compensate, but you should nevertheless check the accuracy of your timers. Use the timer display when a recording is running on the client, and on the server, set TALK_TO_MASTER to 0 and DEDICATED_IDLE to 0.01666666 (that's one minute) and check how long it really is running. The drift you're looking for is about 3%.

belenus · Post by **belenus** » Thu Jan 25, 2007 12:12 am

z-man wrote:It's definitely a real time measurement problem. Either the clock on the server goes slow, or the clock on the client is too fast. It could be possible to compensate, but you should nevertheless check the accuracy of your timers. Use the timer display when a recording is running on the client, and on the server, set TALK_TO_MASTER to 0 and DEDICATED_IDLE to 0.01666666 (that's one minute) and check how long it really is running. The drift you're looking for is about 3%.

Will try to test that tomorrow, hoping that I have some more time... =)

belenus · Post by **belenus** » Sat Jan 27, 2007 2:07 pm

z-man wrote:Use the timer display when a recording is running on the client

Not exactly sure what you mean... =)

z-man wrote:and on the server, set TALK_TO_MASTER to 0 and DEDICATED_IDLE to 0.01666666 (that's one minute) and check how long it really is running. The drift you're looking for is about 3%.

Made those changes, but how am I to check how long it is running? =)

Jonathan · Post by **Jonathan** » Sat Jan 27, 2007 2:22 pm

T: x?

belenus · Post by **belenus** » Sat Jan 27, 2007 2:32 pm

Jonathan wrote:T: x?

Well, that's always on or not? Thought he meant something else. =)

belenus · Post by **belenus** » Sat Jan 27, 2007 2:57 pm

You were right with time problems, the vmware instance was running with the wrong timezone and time was off a little too so I synced it with my local timeserver and it is a lot better now, but only at the beginning of a round, getting worse by time...

...but that still doesn't explain why my notebook is still having major issues even though the notebook and this desktop PC are synced to the same local timeserver. I can only guess that, since WinXP doesn't sync as much as ntp on OpenBSD/Linux it gets slightly off over time.

Well, new recordings attached...

...hope you can see something there.

Website · Post by **Z-Man** » Sun Jan 28, 2007 12:57 am

Ah, it's not the absolute time difference or the time zone, we don't care about that since AA does its own time synchronization. The problem is that the clock on the server runs at a different rate than the clock on the client. The time that is 100 seconds to the server is measured as 103 seconds on the client. Yeah, it's supposed to get worse over the course of a round. At the beginning of a round, the clocks are reset at the same time and synced, but they then run at their own speed. There's sporadic syncs all over the round (once per second), but in your case, the client rejects them all for not being trustworthy; they're just off too far and all look as if the packets have been delayed on the network a lot. Internet play may be possible because with a higher ping, the tolerance levels are increased and the syncs are accepted.

What you're supposed to do: start the client, doing a recording. Take a real world watch and compare the speed of the time display in the upper right corner with the speed of your watch. Measure how long it takes the display to go from 10 seconds to 70 seconds.

belenus · Post by **belenus** » Tue Feb 06, 2007 7:52 pm

Got a client and server package of 0.2.8.2.1 for sparc64, will probably publish just the server tho since I can't test the client. (sparc64 X server won't start)

Will do sparc next, but first I'll update the i386 packages to include the unbashified scripts.

Edit:
Hey, how about adding the hardware architecture to "patch-src_network_nServerInfo_cpp"? =)

Website · Post by **Z-Man** » Tue Feb 06, 2007 9:20 pm

belenus wrote:Edit:
Hey, how about adding the hardware architecture to "patch-src_network_nServerInfo_cpp"? =)

Hmm, I don't think this info matters. In fact, it's already too much info given on the version, you just have to steer clear of "Win Hyprid" servers

belenus · Post by **belenus** » Wed Feb 07, 2007 11:58 am

z-man wrote:Hmm, I don't think this info matters. In fact, it's already too much info given on the version, you just have to steer clear of "Win Hyprid" servers

Was just thinking that even though anyone is able to just change that info anyway it would be nice to see what arch a server is actually running on =)

Ok just sparc64 for OpenBSD it is, no 32 bit sparc since that is an entirely different and really old arch.

Updated the aabeta and mainsite inside repository to include the OpenBSD sparc64 dedicated server. Will add the client later even though I can't test it right now.

belenus · Post by **belenus** » Wed May 02, 2007 11:46 am

Armagetron Advanged 0.2.8.2.1 client and server packages for i386 and sparc64 for the new release of OpenBSD 4.1 are now available at:

http://beta.armagetronad.net/
http://lechtermann.net/pub/OpenBSD/packages/4.1/
http://armagetronad.net/downloads.php (soon)

belenus · Post by **belenus** » Thu May 03, 2007 6:37 am

Your mail to 'Armagetronad-commits' with the subject

SF.net SVN: armagetronad: [7214]
www/beta/trunk/www-aabeta/releases.php

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:

???

Also please update http://www.armagetronad.net/downloads.php since I changed the packages for OpenBSD from 4.0 to 4.1 in repository.

Armagetron Forums

OpenBSD support thread

OpenBSD 4.1 packages available!