Just something I've noticed, I'm sure there are gurus on here that can
add to it, or totally take it apart - I'd like to hear your thoughts.
> 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
>