robots are go

[statespacedev]

brought the robots into utexas folder so everyone can play with em -
also refreshed the readme there - here's the relevant part
https://github.com/drforbin/decwar/tree/master/utexas#robot-players
and a copypasta right here - some curious stuff here...

• three robots - this is fine! they will carry on indefinitely, no problem. twelve straight hours is normal. rarely now and then one will get knocked out to the shell. can simply restart it and away it goes.
• six robots - this will be ok for an hour or two, then utexas will need to be 'rebooted from disk', after making sure all robots are closed out to the shell. this is where any and all help is wanted! utexas running with six robots indefinitely will be a milestone. yes it's actually happened a few times, have seen them go for twelve hours, but seems always under odd circumstances. it's nowhere near robust and reliable!

what we'd like to see is eighteen robots playing indefinitely. first step on that path is the jump from three to six. note that even going from three to four triggers instability. for some reason, the number three is special. three robots or fewer is fine. any more is trouble... now, here comes a bizzare clue... when there is trouble, it very often happens at 'one hour and ten minutes' or 'two hours and twenty minutes' - have not been able to make any sense of this at all, but it's real... have noted from the tops-10 monitor calls manual that the kl and ks processors have an 'apr clock' that's 'based on the frequency of the system power source (either 50 or 60 hz).' could there be a system clock roll-over / overflow / etc? shouldn't it effect three robots as well as six robots?

[drforbin]

What errors do you get?

[statespacedev]

very often the apr trap - 'aprtrp' - in that case, one robot will continue merrily along, but all other robots got knocked out and the system is messed up and has to be rebooted.

some times a 'queue error' - then several robots can kind of survive, or all can get knocked out.

have been trying to figure out a pattern there - there definitely is one. in some conditions/states it's aprtrp, in some it's queue... hmmm

[drforbin]

Does it happen on devel?

[statespacedev]

good question, not sure - am focused on utexas 'going backwards' - will think of a way to setup a test env for 'development branch' - will be some work, but very well could be worth it - good reference baseline for sanity checking utexas!:)

[drforbin]

When you say system has to be reboot I'm sure that is not true.
It's the high segment that is corrupt. run decfix and try again

[statespacedev]

awesome - don't know anything about this - thanks merlyn!!! yep definitely true it's high seg trouble - had no idea how to approach that other than reboot - on it!:)

[drforbin]

The aprtrap(s) I think are for divide by zero and such...I will look into it.

[statespacedev]

have been learning a ton about aprtrp hahaha - yep makes sense! me too, am looking into it for sure

[drforbin]

What decfix does is rename the decwar executable and than name it back again..
When the swapper sees that the executable has been renamed it removes the segment.

do this

sys d

to show currently loaded high segments.

[drforbin]

The source for decfix is in the repo and I changed it all to work with 1,27 using standard calls

[drforbin]

The only call to APRENB is in warmac unber the RESET routines.
I changed alot in this routine.
It's possible these changes will fix your problem

[statespacedev]

cool, will check into that - fwiw 'utexas warmac' is fully synced to 'develop branch warmac' since last weekend - am watching them both like a hawk now in a 'code comparer tool':)

[statespacedev]

had a crazy idea - dug into mongen.do - builds the monitor -
was looking for runtime clock stuff, and it's there -
but noticed a setting for 'number of queues'... was set to 5, hmmmm kind similar to the 'magic three'?
changed that from 5 to 15 - testing now

expect "\r\n\177#"; continue
expect "\r\n\177#"; continue
expect " High priority queues(0,0-15):" send "15\r"; continue. <--------------------------- was 5...
expect "MSGSER(Y,N):" send "Y\r"; continue
expect "PSISER(Y,N):" send "Y\r"; continue
expect "IPCF(Y,N):" send "Y\r"; continue
expect "ENQ/DEQ(Y,N):" send "Y\r"; continue

[statespacedev]

looking good - six robots just passed the 1:10 barrier no prob - if they can pass 2:20...

[statespacedev]

arrrrrrrgh!!! blew up at one hour fifty minutes - thought we were gonna make it!!! hahaha -
well, on to the next try - have been hammering on this for a while now, we're gonna get it!:)

[statespacedev]

wow, interesting - just did a second game - fresh machine -
it blew up at exactly the same point in time! aprtrp at one hour and fifty two minutes to be exact - 1:52
going to try a third game - if this is reproducible - 1:52, 1:52, 1:52 - it'll be saying sooooooooomething
not sure what hahaha, but at least reproducible will help!:) more in a few hours
hmmm...
if it's true, then mongen and mongen.do does have an effect and is a factor!:) that knowledge would be progress

[statespacedev]

argh - nope - not reproducible:( third time aprtrp came at 1:16

[drforbin]

Noah,
It could just be that since your 'robots' are presumably doing the same thing each time and all a computer is a turing/state machine. that the over flow whatever just happenes to be occurring at the same time.

Let me ask you this....did you mongen your monitor?

[statespacedev]

true - good point merlyn!
hmmm, should be getting a random galaxy each time...? and all the events probly shouldn't reproduce exactly?
before queue's from 5 to 15 change, there's was nothing reproducible, that's for sure, hahaha:)
yep - 'step2' does mongen and builds the monitor - what we're messing with here this afternoon is changing the mongen config, nother words 'changing tops10'...

[drforbin]

My suggestion would be to set some prints in the aprtrap routine and see if it's actually traping to the subroutine everytime
If it is, that isolates that it is a trap.

[statespacedev]

good idea, and yep do have some custom prints here in my local version (not the main repo) that do show it's inside aprtrp:)
not sure where it's 'coming from' - but it's definitely getting inside aprtrp, and aprtrp is doing 'monit'
let's see if we get a third '1:52' in a row - that would be super interesting...:)

[statespacedev]

sadly, not reproducible - third time was at 1:16 - so we had 1:52, 1:52, 1:16...

[drforbin]

look and see what the arpenb call is enabling for a trap

[drforbin]

I'll look at it but I'm just trying to give you some ideas.
If your sure it's calling monit than this subroutine must be trapped through aprenb.
The thing to do is look at the bit mask of trappable events.
aprenb is only called ONCE in warmac, it's in the reset routine.

[statespacedev]

thanks merlyn! idea are perfect - know you're not going to be digging into it!
just brainstorming for ideas here:) -
sharing for other coming along later, 'what has happened so far'

[drforbin]

Noah, I will look at it.

[drforbin]

Noah,

can I make a suggestion. Why don't you use the devel branch and run your robots on it and see if the interaction is any different?

[statespacedev]

yep it's definitely one thing can do - am considering how to allocate effort and that's one path can put effort into -
so one consideration is that utexas is built entirely from scratch using tapes - tops10 and game - want to preserve that - no magical environments, everything built 'live on the fly' from tape
and another is that the game code in utexas is synced against devel branch -
what have done in last few days is strip the lock/unlock mac10 down to bare min 'simplest possible' - am confident it's not the prob
still getting aprtrp with more than three robots, after an hour or two - am thinking it's something about tops10 not the game code
probably this weekend will focus on that aprtrp, decode it etc - with lock/unlock eliminated, something in the i/o systems -
maybe something with the disk, something coming every hour or so...? hmmm, something like that - something with i/o resources -
why should three robots be magic, or an hour?... just thinking out loud... hmmmmmmm

[statespacedev]

nother way to look at it - do believe devel branch running in its env is fine!:)
would be considerable effort to use the robots to prove what already believe hahaha - devel branch and env are fine
'from tape' tops10 and utexas have this big question mark because it's both game code and env code together - in a nutshell, unique env!

[drforbin]

Noah, I think we should discuss this if you like.
Let me know.

[statespacedev]

sounds good - want to experiment a bit more - still learning a lot! then will be time to discuss:)

[statespacedev]

stand by... experiment this morning may have got it! starting a second 'confirmation' run soon
if that's good - we'll celebrate:)
definitely know what the change was - found a way to simplify the mac10 lock/unlock code even fuuuuuuuurther...