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