mzucca@verizon.net wrote:

> You may never be able to beat the PSC DMA engine on TX
> because TX using the Sonic's DMA engine will be a read
> across the NuBus to DRAM, which is going to be a two cycle
> operation (I think), whereas, the PSC doing the TX DMA is
> going to be a write to the NuBus which is a single cycle
> operation. So, perhaps the best bet is PSC DMA for TX and
> Sonic DMA for RX. That way, you're only ever doing single
> cycle writes on the NuBus regardless of the transfer
> direction. It's also possible that the PSC DMA can do
> special large block cycles on the NuBus but it's not
> clear if the Sonic can do the same. That's, assuming
> of course, that the current MD Sonic driver we have is
> actually taking complete advantage of the PSC's capabilities. :)

Note, mine is not NuBus based, but Comm Slot one on LC630.

I don't know about the PSC DMA (and mac68k hardware) at all,
but AFAICT, -current MD mac68k's Sonic driver
(mac68k/dev/if_sn.c, which seems derived from old NetBSD/pica port
 and was intended as "MI" driver in the old days when MI bus APIs
 didn't exist) doesn't access such "PSC DMA" device at all. 

Anyway, as per ttcp output, it looks that bottleneck is
CPU ops, not DMA xfer rate (i.e. no idle CPU time on xfer). 
---
Izumi Tsutsui