[nos-bbs] Discussion about JNOS 'slowness' ...

[Maiko Langelaar]

First of all, I hope everyone had an okay christmas. As well, I
would like to wish everyone the best for the upcoming new year.

Has JNOS always been 'slow' ?

This might be hard for me to explain, but when you are connected
to a JNOS station and you hit enter to send a command, you may have
noticed it might take a 'second' for it to be 'processed'. It's not
a lightning fast response time is it now. I noticed this while trying
to connect to my own JNOS via a 3 'wire' led/phototransistor dummy
serial load (bounces data right back at the same interface). And to
be frank, I've noticed it in many other occasions. Forwarding should
never take so long, netrom is always painfully slow, and so on.

Was it always like this (for the linux version) ?

Or did this start happening back when I did the kernel change, back
when I was somewhat forced to use the setcontext() functions instead
of setjmp() calls and such. Version 2.0e and earlier use setjmp()
methodology, 2.0f and older use the setcontext() functions.

Was the DOS version the same too ?

SOOOO - Want to see JNOS go like lightning ? It's easy enough :

    edit timer.h, change MSPTICK to 1 (normally it's 55)

    rm domain.o main.o rspf.o timer.o unix.o

    make

CONSEQUENCES - your timers will expire much faster now, but the system
clock will be fine. But as an experiment, give it a try, tell me what you
think. Not sure if this was always the way it was, perhaps due to 
inadequate CPU for it's time, I don't know.

I'm going to play with this a bit, a patch will be released in the near
future so that the timers behave, but JNOS will suddenly come to life !

I've known about this for some time, but my experimenting that I've been
doing over the christmas holidays kinda brought it up again. Never thought
how noticing the delay between laser diode flashes can refresh one's 
memory on the topic.

Maiko Langelaar / VE4KLM