u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) (03/26/91)
Hello world, yesterday I made a cleanup in my kernel/mm files. I am using PC 1.5.10 MINIX with Gordon Irlam's virtual consoles, Gary Oliver's shared text segments, Kai-Uwe Bloem's nice scheduler (without profil!) and a third serial line (AT only - sorry for XTs). The last patch is my own work and very simple. The third serial line uses the same interrupt like a winchster in XTs, it was the only free interrupt on my card. It will be activated by setting NR_RS_LINES to three. I still have the original sources, which would allow to make context diffs for a upgrade kit. I can include a simple cdiff for login, which allows correct wtmp/utmp records with terminal minor numbers greater than 9. If someone is interested, I will make these diffs and put them on a ftp server. My current version (three serial lines, four virtual terminals) needs 165 KBytes, but it allows nice working. I am unable to reach Gary Oliver via mail. If modified his mu (memory used) to work with psdatabase. Is someone out there who can reach him? Has anyone tried to increase the number of disk buffers in standard PC MINIX? Does it give reasonable speed improvements? I heard some rumours about bad performance of serial lines in PC MINIX. It's not true at all. One of my terminals uses 19200 baud. I displayed my german dictionary on it which results in more than 1700 characters per second (7 data bits, one parity bit, one start and one stop bit) equals more than 17000 baud *effective* transfer rate. Sounds like good performance to me. These values are measured on a 386 machine with the provided assembler drivers. I vote for comp.os.minix.splitgroups. It seems that this discussion comes up each year with increasing length :-(. Most faq's can be answered by a regular posting of the MINIX information sheet. *This* will reduce net bandwidth. I would not like a moderated MINIX group. Subgroups for the different machines are bad, because it encourages machine specific things. The only argument for splitting this group may be to easy automatic archiving. What about comp.os.minix[.disc] and comp.os.minix.arch? The archive group contains only articles, which the author wants to be archived, because they contain sources, patches or important documents, the discussion group contains anything else. Namaskaar Michael Haardt
adrie@philica.ica.philips.nl (Adrie Koolen) (03/28/91)
In article <4177@rwthinf.UUCP> u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) writes: >Has anyone tried to increase the number of disk buffers in standard PC >MINIX? Does it give reasonable speed improvements? On my SparcStation, I use a diskbuffer of 1536 blocks (1.5MB). When performing a make, this speeds things up quite a bit (Minix-Sparc uses the GNU C compiler)! >I heard some rumours about bad performance of serial lines in PC MINIX. >It's not true at all. One of my terminals uses 19200 baud. I displayed >my german dictionary on it which results in more than 1700 characters >per second (7 data bits, one parity bit, one start and one stop bit) >equals more than 17000 baud *effective* transfer rate. Sounds like good >performance to me. These values are measured on a 386 machine with the >provided assembler drivers. For speedy RS232 performance, you need at least two things: a reasonable efficient RS232 driver and efficient task switching routines. Every time the serial controller wants to send (or has received) a byte, it issues an interrupt and the the currently running task has to be interrupted. This means saving the processor state and performing some administration. On a PC, these thing can (and will) be done relatively fast. On a Sparc- Station it's somewhat slower, the Sparc processor has 120 32-bit general purpose registers and also 32 floating point registers have to be saved when the interrupted process uses them. Still on a 20MHz SparcStation, I just measured a throughput of 1840 bytes per second at 19200 baud and the CPU isn't even half used. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
dgraham@bmerh451.bnr.ca (Douglas Graham) (03/29/91)
In article <786@philica.ica.philips.nl> adrie@beitel.ica.philips.nl (Adrie Koolen) writes: >On a Sparc- >Station it's somewhat slower, the Sparc processor has 120 32-bit general >purpose registers and also 32 floating point registers have to be saved >when the interrupted process uses them. Yow! That's a lot of register saving. I thought that one of the neat features of the SPARC architecture was it's register windows. As long as there is a window of (16?) registers available when an interrupt occurs, no registers need to be saved at all by the ISR. And as long as the ISR doesn't use the FPU, there shouldn't be any need to save floating pointing registers. 'course for a full context switch, you'd have to save all registers. I guess the problem is that Minix does a full context save and restore in response to an interrupt, even if all the ISR wants to do is grab a character from the UART, stuff it into a buffer, and then return to the interrupted process. --- Doug Graham dgraham@bnr.ca Bell-Northern Research, Ottawa Ontario Canada
waltje@minixug.mugnet.org (Fred 'The Rebel' van Kempen) (03/30/91)
Michael Haardt wrote: > can include a simple cdiff for login, which allows correct wtmp/utmp > records with terminal minor numbers greater than 9. If someone is Has already been done - to be posted next week. > interested, I will make these diffs and put them on a ftp server. My > current version (three serial lines, four virtual terminals) needs 165 > KBytes, but it allows nice working. Oh well. Advanced MINIX 1.5.10E-PC/286 is about 349Kbyte :-) > I am unable to reach Gary Oliver via mail. If modified his mu (memory > used) to work with psdatabase. Is someone out there who can reach him? No, but pse send me the mu... > Has anyone tried to increase the number of disk buffers in standard PC > MINIX? Does it give reasonable speed improvements? As said before, the FS cache resides in FS data space. So, we're limited to about 30 or 40 buffers... I have some ideas on how to change this, but I am unsure about what the drop in performance would be... :-( > I heard some rumours about bad performance of serial lines in PC MINIX. > It's not true at all. One of my terminals uses 19200 baud. I displayed > my german dictionary on it which results in more than 1700 characters > per second (7 data bits, one parity bit, one start and one stop bit) > equals more than 17000 baud *effective* transfer rate. Sounds like good > performance to me. These values are measured on a 386 machine with the > provided assembler drivers. On an "standard" 12MHz AT (286) clone, the effective rate drops significantly on speeds above and including 9600bps. On MUGNET, we just had a discussion about this, which resulted in the following tables: (taken from mugnet.talk art. 42, without persmission) 8MHz 8088 clone 12MHz 80286 clone -------------------------------- ------------------------- 16kB 128kB 256kB 512kB 16kB 128kB 256kB 512kB 1200 97.5 99.7 -- -- 98.9 99.8 99.8 99.6 2400 96.2 99.1 -- -- 98.9 99.8 99.8 99.6 4800 94.8 98.2 99.1 98.8 97.5 99.7 99.7 99.6 9600 85.3 95.5 96.8 97.3 94.8 98.9 99.3 99.3 19200 71.1 92.3 92.8 93.8 94.8 98.9 98.2 98.2 So, it is obvious that the XT gets hit by interrupt latency (read: system context switches) at higher speeds. At 19200bps, the poor thing gets hit by 1920 interrupts per second... The assembler driver runs well, but still does not work OK at very high speeds on not-so-fast machines. So, I thought of a way to improve this for our Advanced MINIX.. The answer is, obviously, different hardware. New UART chips are available for the PC, which have a 16-byte FIFO in them. This means, that, when properly programmed, the system receives only one interrupt per 14 or so characters, reslulting in much less system overhead. However, the (PC-MINIX) serial drivers were not designed for that. So, I restructered them to be able to use FIFO chips at full blast. This resulted in a true 100% (sometimes even 100.4%, maybe a rounding error? :-) line efficiency at speeds up to 115Kbps. The changes were relatively simple (in rs232.c, only some code to see if a FIFO UART was present, and some code to set flags in struct rs232). The assembly driver was completely rewritten, but mostly because I hated its structure.... Anyway. Advanced MINIX now is able to run at speeds up to 115Kbps, without going nuts or losing data. This is nice for local links (like the ones I have to the "uwalt*" machines here) or Telebit modems... If someone can tell me how to make a complete set of cdifss relative to 1.5.10, I will do that and post them here... Fred. "An Operating System is what the _USERS_ think of it- me"
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/01/91)
Of course, IF there is a free window, you can use it. But then, you cannot predict if there will be a window overflow that will save a window. C.v.W.