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
|