<div dir="ltr">Luckily, I don't mind being wrong (or even _way_ off the mark).<div><br></div><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I don't think that's it.<br>
<br>
First a nitpick: the PowerBook version of the late-model G4 (7447A) doesn't have the external L3 cache interface, so it only has the 256KB or 512KB internal L2 cache (I forget which). The desktop version (7457A) used external cache. The G4 was considered to be *crippled* by its FSB by the end of its run, since it never adopted high-performance signalling techniques, nor moved the memory controller on-die; it was quoted that the G5 (970) could move data using *single-byte* operations faster than the *peak* throughput of the G4's FSB. The only reason the G5 never made it into a PowerBook was because it wasn't battery-friendly in the slightest.<br>
</blockquote><div><br></div><div>And the specs on the G4 that I'd dug up were desktop specs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
But that makes little difference to your argument - compared to a cheap CPE-class embedded SoC, the PowerBook is eminently desktop-class hardware, even if it is already a decade old.<br>
<br>
More compelling is that even at 16-bit width, the WNDR's RAM should have more bandwidth than my PowerBook's PCI bus. Standard PCI is 33MHz x 32-bit, and I can push a steady 30MB/sec in both directions simultaneously, which corresponds in total to about half the PCI bus's theoretical capacity. (The GEM reports 66MHz capability, but it shares the bus with an IDE controller which doesn't, so I assume it is stuck at 33MHz.) A 16-bit RAM should be able to match PCI if it runs at 66MHz, which is the lower limit of JEDEC standards for SDRAM.<br>
<br>
The AR7161 datasheet says it has a DDR-capable SDRAM interface, which implies at least 200MHz unless the integrator was colossally stingy. Further, a little digging suggests that the memory bus should be 32-bit wide (hence two 16-bit RAM chips), and that the WNDR runs it at 340MHz, half the CPU core speed. For an embedded SoC, that's really not too bad - it should be able to sustain 1GB/sec, in one direction at a time.<br>
</blockquote><div><br></div><div>The kernel boot messages report 170MHz DDR operation, for 340MHz data-rates.</div><div><br></div><div>But, I don't think it's 32-bit, I think it's running two banks of 64MB chips in x16 mode. That's based on my experiences with other, similar chips. The AR7161 datasheet here: <a href="https://wikidevi.com/files/Atheros/specsheets/AR7161.pdf">https://wikidevi.com/files/Atheros/specsheets/AR7161.pdf</a> notes it's DDR1, but not the bus width.</div>
<div><br></div><div>But even if it had an 8-bit bus, it sounds like it would have the ability to move packets pretty well, so that's not the case (2Gbps vs. 8Gbps)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So that takes care of the argument for simply moving the payload around. In any case, the WNDR demonstrably *can* cope with the available bandwidth if the shaping is turned off.<br>
<br>
For the purposes of shaping, the CPU shouldn't need to touch the majority of the payload - only the headers, which are relatively small. The bulk of the payload should DMA from one NIC to RAM, then DMA back out of RAM to the other NIC. It has to do that anyway to route them, and without shaping there'd be more of them to handle. The difference might be in the data structures used by the shaper itself, but I think those are also reasonably compact. It doesn't even have to touch userspace, since it's not acting as the endpoint as my PowerBook was during my tests.<br>
</blockquote><div><br></div><div>In an ideal case, yes. But is that how this gets managed? (I have no idea, I'm certainly not a kernel developer).</div><div><br></div><div>If the packet data is getting moved about from buffer to buffer (for instance to do the htb calculations?) could that substantially change the processing load?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And while the MIPS 24K core is old, it's also been die-shrunk over the intervening years, so it runs a lot faster than it originally did. I very much doubt that it's as refined as my G4, but it could probably hold its own relative to a comparable ARM SoC such as the Raspberry Pi. (Unfortunately, the latter doesn't have the I/O capacity to do high-speed networking - USB only.) Atheros publicity materials indicate that they increased the I-cache to 64KB for performance reasons, but saw no need to increase the D-cache at the same time.<br>
</blockquote><div><br></div><div>But, they also have a core that's designed to do little to no processing of the data, just DMA from one side to the other, while validating the firewall rules... So it may be sufficient d-cache for that, without having the capacity to do anything else.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Which brings me back to the timers, and other items of black magic.<br>
</blockquote><div><br></div><div>Which would point to under-utilizing the processor core, while still having high load? (I'm not seeing that, I'm curious if that would be the case).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Incidentally, transfer speed benchmarks involving wireless will certainly be limited by the wireless link. I assume that's not a factor here.<br></blockquote><div><br></div><div>That's the usual suspicion. But these are RF-chamber, short-range lab setups where the radios are running at full speed in perfect environments...</div>
<div><br></div><div>======</div><div><br></div><div>What this makes me realize is that I should go instrument the cpu stats with each of the various operating modes:</div><div><br></div><div>* no shaping, anywhere</div><div>
* egress shaping</div><div>* egress and ingress shaping at various limited levels:</div><div> * 10Mbps</div><div> * 20Mbps</div><div> * 50Mbps</div><div> * 100Mbps</div><div><br></div><div>-Aaron</div></div></div>
</div></div>