steveg@tove.umd.edu (Steve Green) (07/30/89)
I am a new unixpc user, but it seems that when I do a cu to another unix machine at 9600 baud (a Mac II) it moves like molasses. Curses games are as unplayable as on a 2400 baud modem but the mac says that we are indeed moving at 9600, I have eliminated all other windows and processes that can be delt away with. Could someone please tell me if this is normal or what I am doing wrong. Please reply via mail. -thanks Steve disclaimer- I am not responsible.
stevens@hsi.UUCP (Richard Stevens) (07/30/89)
In article <18818@mimsy.UUCP>, steveg@tove.umd.edu (Steve Green) writes: > > I am a new unixpc user, but it seems that when I do a cu to another unix > machine at 9600 baud (a Mac II) it moves like molasses. The first problem is that cu does a read() system call of 1 byte from the communications line, followed by a write() of 1 byte to the standard output. This loop is the heart of cu, and it is slow as molasses on the 3b1. There's no way around this, unless you have the source to a cu. You should run some other terminal emulator instead (assuming there is one that doesn't have this basic limitation). The second problem is that the 3b1 console can't run at 9600. Cat a big file to the screen and time it - it's about 5500 baud max. I'd guess this is due to the implementation of the ansi driver for the console, as I've heard that an attached terminal can indeed run at 9600. Richard Stevens Health Systems International, New Haven, CT stevens@hsi.com ... { uunet | yale } ! hsi ! stevens
root@spdyne.UUCP (08/01/89)
In article <18818@mimsy.UUCP>, steveg@tove.umd.edu (Steve Green) writes: > > I am a new unixpc user, but it seems that when I do a cu to another unix > machine at 9600 baud (a Mac II) it moves like molasses. Written by stevens@hsi.UUCP > The first problem is that cu does a read() system call of 1 byte from > the communications line, followed by a write() of 1 byte to the standard I don't think that this is the major problem..... > The second problem is that the 3b1 console can't run at 9600. > Cat a big file to the screen and time it - it's about 5500 baud max. Which is not all that bad, considering it's running in Graphics mode! On a PC all you have to do is to put 1 byte in 1 location in memory. On the 7300, I belive you would have to update at least 14 bytes. This would make it about 14 times slower. (Assuming a 14x8 char set, But I think that it is a 14x9, thus one would have to *modify* (read then write) 28 bytes. As well as do a bunch of And's & Xor's.. ) This could make it about about 60 times slower -- Just because it's in graphics mode... The Mac had the same problem when it first came out.. (as I recall..) And scrolling you have to move the entire graphics image. Chert Pellett root@spdyne PS: I'm not knocking the 7300/3b1... I like being in Graphics mode... I was raised on PLATO.... (And GIGI's on VMS...)
wtm@neoucom.UUCP (Bill Mayhew) (08/04/89)
Part of the limitations of throughput with the stock version of cu supplied with [version 3.51 software of] the 3b1/Unix PC is that the main loop only reads and puts one character to the screen at a time; which is horribly slow, as you might guess. A better way to work is to write a block of characters to the console at once. This requires a little more work, as the input routine shoud set a timer that forces it to dump a short block if the requisite amount of characters haven't been received in n milliseconds. By the way, the 3b1 console makes almost 4800 baud effective rate when catting a file from the local winchester, so you'll be somewhat constrained by that. (Kinda hard to read faster than thant anyway!) There isn't much that can be done in the way of trying to patch the stock cu. There are a number of publicly available terminal emulators that do work, however. I use C-kermit 4E(070) dated Jan 29, 1988 on my 3b1 here. I use a PC7300 termcap on the vax I talk with and have no problems. Pcomm was posted to the net a while back, and it looks very much like procomm of the msdos world; I have not used pcomm, but have heard good comments. You can also try to get your mits on the illusory Honey DanBer uucp package, as it has a fixed cu with it. Bill wtm@impulse.UUCP or wtm@neoucom.UUCP
roger@banzai.UUCP (Roger Florkowski) (08/07/89)
In article <1696@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: > >Part of the limitations of throughput with the stock version of cu >... the main loop only reads and puts one character to the screen at a > >... try to get your mits on the illusory Honey DanBer uucp package, as >it has a fixed cu with it. > There is a public version of cu (called CU) which uses dial(), located on alphacm, a BBS site which also accepts anon-uucp. It has the 'read one char.... write one char' loop which IS very slow. A note about CU: it has been modified to accept xmodem/ymodem transfers, so it is very useful to those who call BBS sites. I also have the HDB version, and it flies in comparison. -- Roger Florkowski {uunet!uvm-gen, attmail}!banzai!roger The People's Computer Company `Revolutionary Programming'