filbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/18/89)
In article <8909180719.AA29678@postgres.Berkeley.EDU> Matt Dillon writes: > Now that I have NET: working w/ my parallel port network (raw > throughput of 28KBytes/sec), having a second Amiga has suddenly become > useful, much more useful than spending the $$ for an accelerator. Perhaps; certainly a big round of applause are due you and Doug Walker. This doesn't solve the memory problem on the 2nd machine; perhaps the VM routines discussed by -- I forget his name -- in an article titled something like "Exit with a bang!"? (Aside: I never saw even a single reply to that message. Did everyone assume it was a hoax? Was it old hat? I was expecting a flurry of discussion.) I'm very excited by the great PD/ShareWare work that is being done on AmigaDOS -- from ARP, AREXX and ConMan to DNET, NET:, the parallel network driver, and potentially virtual memory, maybe even memory protection. And hardware like LUCAS/FRANCES and the ECS hack for the A1000. Hopefully Commodore will see fit to license some of the software parts. AmigaDOS deserves it; new buyers deserve these features without having to become experts on what's good and what isn't in PD software. > diskperf NET: to my A1000's RAM: drive yields 25 KBytes/sec > (4096 byte buffers). Raw network throughput is 28 KBytes/sec. Is that the theoretical limit on the parallel port? I'd expect much higher throughput. The serial port can be driven up to 56Kbps or so, right? If (and I realize I'm making a big assumption here, but ...) IF it takes about the same amount of effort to send a BYTE down the parallel port as a BIT down the serial port, shouldn't the limit be around 56Kb/sec? Hmmm. 2:1. Less of a difference than I'd thought at first. I'm probably just talking through my hat; ignore me... ;-} Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (09/19/89)
:> diskperf NET: to my A1000's RAM: drive yields 25 KBytes/sec
:> (4096 byte buffers). Raw network throughput is 28 KBytes/sec.
:Is that the theoretical limit on the parallel port? I'd expect much
:higher throughput. The serial port can be driven up to 56Kbps or so,
:right? If (and I realize I'm making a big assumption here, but ...)
:IF it takes about the same amount of effort to send a BYTE down the
:parallel port as a BIT down the serial port, shouldn't the limit be
:around 56Kb/sec?
I've been talking to Ron Perry, who wrote the basic software
for a commercial 16 Amiga server using the parallel port. With
hardware, he is getting 100KBytes/sec out of it.
As far as the serial port goes, no, a bit is not the same
trouble as a byte on the parallel port. You write bytes to the
serial port register not bits so the trouble is the same.
56Kbps = 5.6KBytes/sec (10 bits/byte 8 bits + start + stop)
The current 28KBytes/sec throughput I'm getting over the
parallel port is about 35uS/byte. Most of the time is spent
hand-shaking between the computers. With the Amiga you can't
count cycles like you could on the old C64's and PETs so you
have to handshake.
:Hmmm. 2:1. Less of a difference than I'd thought at first. I'm
:probably just talking through my hat; ignore me... ;-}
nearer to 5:1. Theoretically, the maximum transfer rate over
the parallel port is ~8 to ~10x the maximum transfer rate over a
serial port using line loading limits.
I've heard people running the serial port at 262KBaud
(26KBytes/sec). The only way this can be done that I can think
of is (1) The machine must have FAST memory so the video doesn't
interfere, and (2) Interrupts must be disabled during the transfer.
That might be good for a hack file transfer but I can't make those
assumptions for interactive usage.
-Mattfilbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/19/89)
In article <8909182019.AA06478@postgres.Berkeley.EDU> Matt Dillon writes: > As far as the serial port goes, no, a bit is not the same > trouble as a byte on the parallel port. You write bytes to the > serial port register not bits so the trouble is the same. I meant, in essence, "the same trouble to the hardware". i.e. if it can change the state of the serial data line 56K times/sec., it's pretty reasonable that it'd be able to change ALL the parallel lines 56K/sec. But you're saying 28K/sec. is a software limit, so hardware capability isn't even at question. > The current 28KBytes/sec throughput I'm getting over the > parallel port is about 35uS/byte. Most of the time is spent > hand-shaking between the computers. With the Amiga you can't > count cycles like you could on the old C64's and PETs so you > have to handshake. > I've heard people running the serial port at 262KBaud > (26KBytes/sec). The only way this can be done that I can think > of is (1) The machine must have FAST memory so the video doesn't > interfere, and (2) Interrupts must be disabled during the transfer. > That might be good for a hack file transfer but I can't make those > assumptions for interactive usage. What happens if you Forbid() as the block starts, can you get away with cycle counting? If the blocks are short enough this should not affect the rest of the system. (e.g. suppose this gets it down to 15uS/byte; at 64 bytes/block that's about 1ms, just barely short enough to not interfere with 9600bps serial I/O -- hopefully). You could let the user set max. block length and whether to use handshaking or cycle counting. You could even have a library to allow programs to change that; and include a user agent that lets the user directly set them with sliders etc. The same idea should apply to the serial port: crank it up to 262Kbps or whatever, and transfer small packets within Forbid(). You >can< get away with these assumptions for interactive usage, if you never stop the machine for long enough for a user to notice. 1ms is fine. The receiver should in general control the transfer, asking for another block when it is given CPU time. Transfer rate would vary a lot according to system load, but that's normal. Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/19/89)
In article <33.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes:
<I'm very excited by the great PD/ShareWare work that is being done on
<AmigaDOS -- from ARP, AREXX and ConMan to DNET, NET:, the parallel
Um, AREXX is neither PD nor shareware; it's a real live commercial
product. If you've got a copy you didn't pay for, or have been passing
it out, you've been violating the copyright laws.
<mike
--
Here's a song about absolutely nothing. Mike Meyer
It's not about me, not about anyone else, mwm@berkeley.edu
Not about love, not about being young. ucbvax!mwm
Not about anything else, either. mwm@ucbjade.BITNETfilbo@gorn.santa-cruz.ca.us (Bela Lubkin) (09/19/89)
In article <1989Sep19.004336.17535@agate.berkeley.edu> Mike Meyer writes: >Um, AREXX is neither PD nor shareware; it's a real live commercial >product. If you've got a copy you didn't pay for, or have been passing >it out, you've been violating the copyright laws. Actually, I don't have a copy at all. It's one of those "must get some day" items on my list. Partly I haven't moved on it because I bought REXX for my PClone long ago and was quite underwhelmed. But it's a lot more valuable on a multitasking machine. Undoubtably, once I install it I'll wonder how I ever got along without it... Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (09/19/89)
:What happens if you Forbid() as the block starts, can you get away with
:cycle counting? If the blocks are short enough this should not affect
:the rest of the system. (e.g. suppose this gets it down to 15uS/byte;
You can't. Too much effects the 68K and, in fact, there may not
even be a 68K in there... could be a 68020 or 030 or, well, you get
the point.
Also things like video (say the guy doesn't have any FAST mem!)
and, of course, hardware interrupts would cause major problems.
(You simply don't disable interrupts for that long a period of time!)
-Mattdaveh@cbmvax.UUCP (Dave Haynie) (09/19/89)
in article <33.filbo@gorn.santa-cruz.ca.us>, filbo@gorn.santa-cruz.ca.us (Bela Lubkin) says: > X-Claimer: I >am< R Pentomino! > This doesn't solve the memory problem on the 2nd machine; perhaps the VM > routines discussed by -- I forget his name -- in an article titled > something like "Exit with a bang!"? (Aside: I never saw even a single > reply to that message. Did everyone assume it was a hoax? Was it old hat? > I was expecting a flurry of discussion.) There was LOTS of VM discussion around here back around June or so. I guess that someone has it working to a degree by now isn't that amazing, at least if you were tuned into the earlier discussion. Of course, the idea of some kind of VM working on an MMU equipped Amiga isn't that big an issue -- I would guess anyone with a little OS and MMU programming experience could get _something_ working in a week or two of after-hours hacking. The real test is how some of the extremely sticky issues (start with "I get a page fault while I'm Disabled()" and take it from there) are handled. > IF it takes about the same amount of effort to send a BYTE down the > parallel port as a BIT down the serial port, shouldn't the limit be > around 56Kb/sec? There's a fixed hardware limit at work -- how fast can you talk to the I/O chips. The parallel port is based on an 8520 CIA chip; it takes roughly 10 7.16MHz clocks to write one byte to this chip. The serial port is part of the Paula chip; as long as you're not letting the blitter steal cycles, it usually takes 4 7.16MHz clocks to write one byte to this chip. You'll have to work some kind of handshaking into the parallel transfer as well. So from the CPU point of view alone, the CIA takes at least 5x as long to send a byte as the serial port. Now, the serial port isn't going to shift out that byte in one bus cycle, but it also doesn't occupy the CPU while it's shifting and all. The serial speed, then, will be bound by the speed of Paula's shift register and the quality of the transmission line. The parallel port speed will be bound by the speed of CPU writes, your handshaking mechanism, the quality of its transmission line. > Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 > @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] > R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
daveh@cbmvax.UUCP (Dave Haynie) (09/19/89)
in article <34.filbo@gorn.santa-cruz.ca.us>, filbo@gorn.santa-cruz.ca.us (Bela Lubkin) says: > X-Claimer: I >am< R Pentomino! > What happens if you Forbid() as the block starts, can you get away with > cycle counting? One big problem is that you never know exactly how long it'll take to write to the CIA chip. It's hooked into the system via the 68000's 6800 family support mechanism. The CIA runs from a clock that's 6 68000 clocks low, 4 clocks high. When you access the CIA, the 68000 will synchronize to this free running 716kHz clock; depending on where the 68000 cycle is in relation to the CIA cycle, this can sync-up can vary quite a bit. So handshaking between machines is a requirement. > Bela Lubkin * * filbo@gorn.santa-cruz.ca.us CIS: 73047,1112 > @ * * ...ucbvax!ucscc!gorn!filbo ^^^ REALLY slow [months] > R Pentomino * Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945 -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (09/20/89)
:in article <34.filbo@gorn.santa-cruz.ca.us>, filbo@gorn.santa-cruz.ca.us (Bela Lubkin) says:
:> X-Claimer: I >am< R Pentomino!
:
:> What happens if you Forbid() as the block starts, can you get away with
:> cycle counting?
:
:Dave Haynie Commodore-Amiga Writes: (daveh@cbmvax.commodore.com)
:One big problem is that you never know exactly how long it'll take to write
:to the CIA chip. It's hooked into the system via the 68000's 6800 family
:support mechanism. The CIA runs from a clock that's 6 68000 clocks low,
:4 clocks high. When you access the CIA, the 68000 will synchronize to this
:free running 716kHz clock; depending on where the 68000 cycle is in relation
:to the CIA cycle, this can sync-up can vary quite a bit. So handshaking
:between machines is a requirement.
Oh, THAT is why the cycles weren't comming out! I'm getting
28KBytes/sec out of the thing which is 35uS/byte and I just couldn't
figure out why it was taking so long! Now it's obvious, I only
access the CIA in just about every instruction!
-Mattaca@nyit.UUCP (Al Arthur) (09/21/89)
In article <1989Sep19.004336.17535@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >Um, AREXX is neither PD nor shareware; it's a real live commercial >product. If you've got a copy you didn't pay for, or have been passing >it out, you've been violating the copyright laws. > <mike Actually, I think there was an "ARexx Demo" version in circulation, that didn't have the full functionality of the commercial version. If my memory serves me correctly (it's questionable :-) ), the demo I had, before I bought ARexx, came from the distribution of the WShell, though I think I must have seen it somewhere else. - Al - -- Alex Arthur, System Programmer/UUCP Administrator New York Institute of Technology - Computer Graphics Laboratory Gerry House, Old Westbury, New York 11568 Phone:(516) 686-7644 UUCP: ...!philabs!nyit!aca