G'day,
Dave Taht and I have had a couple of phone conversations now, and he's
convinced me that rather than inserting the netem delay on each laptop,
that latency should be added by a seperate device. To this end, I've got
another little PC and a NIC coming, so that I can repeat all the tests
> On 15 Oct, 2023, at 11:29 pm, David P. Reed via Cake
> wrote:
>
> Of course, Internet congestion control, in general, is still stuck in the
> original Van Jacobsen sawtooth era. My guess is it won't get fixed, though I
> applaud Cake, and despair the hardware folks who keep adding buffers.
60K pings per second? Well, that's probably fast enough for Cake work..., but
I'm sure you can do a LOT better... Try AF_XDP and/or DPDK. I think AF_XDP
works on ARM.
https://adarsh-kumar-phe15.medium.com/receiving-14-million-network-packets-per-second-a9d5cc1408b6
Now admittedly, my
Oh thanks Sebastian. I have irtt installed, but it looks like I need to
start the server. That's easy. Doing it now.
( Incidentally, I did write a golang based icmp pinger. It can ping at
very high rates: https://github.com/edgio/icmpengine. Really should write
one with rust using
really lovely, thank you. I hope we can get flent fixed. That risc
result was awful. Does it have BQL? Are there specs on the ethernet
interface?
This risc-v beaglebone just came out today:
https://www.beagleboard.org/boards/beaglev-ahead
On Sun, Oct 15, 2023 at 8:11 AM dave seddon wrote:
>
>
If I recall correctly, flent will use irtt for its delay probes if available on
both ends. Sure fixing fping seems like a good thing longer term, but to get
data in quickly, maybe try irtt instead?
On 15 October 2023 17:11:23 CEST, dave seddon via Cake
wrote:
>G'day,
>
>I've put more work
G'day,
I've put more work into a test framework around the qdisc tests, but
unfortunately flent doesn't work easily with Ubuntu LTS (
https://github.com/tohojo/flent/issues/232, which I think is an issue with
flent parsing the fping output ).
Results and graphs in this sheet:
My bad. There's a bug for this Looks like I have to downgrade fping
https://github.com/tohojo/flent/issues/232
https://github.com/schweikert/fping/issues/203
On Fri, Oct 13, 2023 at 8:59 AM dave seddon
wrote:
> G'day,
>
> I've been working away on automation of the tests. Pretty close to
G'day,
I've been working away on automation of the tests. Pretty close to having
much nicer tests with a lot more details. I've also got the risc-v device
working.
However, I've run into something funny with flent. Flent is not happy with
fping or ping.
> On Sep 28, 2023, at 15:19, David Lang wrote:
>
> On Thu, 28 Sep 2023, Sebastian Moeller via Cake wrote:
>
>> P.S.: I am tempted, but will likely wait until they are available in
>> quantity and hope that the street price comes down a bit before getting one
>> ;)
>
> They aren't available
On Thu, 28 Sep 2023, Sebastian Moeller via Cake wrote:
P.S.: I am tempted, but will likely wait until they are available in quantity
and hope that the street price comes down a bit before getting one ;)
They aren't available at all yet, and it's not clear when they will be
available.
Hi Jonathan,
> On Sep 28, 2023, at 14:33, Jonathan Morton wrote:
>
>> On 28 Sep, 2023, at 3:15 pm, Sebastian Moeller wrote:
>>
>> This promises even better performance for loads like cake than the already
>> pretty nifty pi4B
>
> Well, increased computing performance is always welcome -
On Thu, 28 Sep 2023, Jonathan Morton via Cake wrote:
On 28 Sep, 2023, at 3:15 pm, Sebastian Moeller wrote:
This promises even better performance for loads like cake than the already
pretty nifty pi4B
Well, increased computing performance is always welcome - but as I've said
before, in
> On 28 Sep, 2023, at 3:15 pm, Sebastian Moeller wrote:
>
> This promises even better performance for loads like cake than the already
> pretty nifty pi4B
Well, increased computing performance is always welcome - but as I've said
before, in most cases I don't think CPU performance is the
Hi Jonathan
> On Sep 28, 2023, at 13:44, Jonathan Morton via Cake
> wrote:
>
>> On 19 Sep, 2023, at 1:07 am, Jonathan Morton wrote:
>>
>>> Raspberry Pi 4's just aren't very good at networking because of their I/O
>>> architecture on the board, just as they are slow at USB in general. That's
> On 19 Sep, 2023, at 1:07 am, Jonathan Morton wrote:
>
>> Raspberry Pi 4's just aren't very good at networking because of their I/O
>> architecture on the board, just as they are slow at USB in general. That's
>> why the CM4 is interesting. It's interesting that the PiHole has gotten so
>>
> On 19 Sep, 2023, at 1:52 am, dave seddon wrote:
>
> I'd love to understand the difference between the tests I've been doing and
> your tests.
> • How many TCP flows did you have please ( cake performance seems to
> drop significantly with increased number of TCP flows, although I need
Thanks Jonathan!
Curious and curiouser
I'd love to understand the difference between the tests I've been doing and
your tests.
- How many TCP flows did you have please ( cake performance seems to
drop significantly with increased number of TCP flows, although I need to
do more testing
> On 18 Sep, 2023, at 10:50 pm, dave seddon via Cake
> wrote:
>
> The cake tests so far had rtt 1ms and rtt 3ms, which might be too low. ( If
> it is too low, then maybe it would make sense to remove "rtt lan = rtt 1ms"
> option, as it's a misleading configuration option? )
If all your
> On 18 Sep, 2023, at 11:24 pm, David P. Reed via Cake
> wrote:
>
> I'm curious, too! We know that on older home routers, with really slow MIPS
> processors, Cake struggles with GigE. As these old MIPS designs get phased
> out and replaced by ARM designs, it will matter.
All qdiscs struggle
On Monday, September 18, 2023 3:50pm, "dave seddon via Cake"
said:
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
> G'day Mr David Reed,
>
> Thanks for the comments.
>
> Definitely agree with
G'day Mr David Reed,
Thanks for the comments.
Definitely agree with your sentiments and the tests definitely do NOT
simply represent Intel verse ARM.
Perhaps I should have been more clear about the objectives of the testing:
I'm curious to understand the performance of these lower end SoC
I appreciate the effort that went into this testing. However, there are some
signficant concerns regarding saying that this is typical ARM64 performance.
(ARM64 easily beats many Intel x86_64 CPUs, if the motherboards are designed
for that - I have a very nice SolidRun 16 core ARM64 board based
On Monday, 18 September 2023, Dave Taht via Cake wrote:
> A huge thanks to dave seddon for buckling down and doing some comprehensive
> testing of a variety of arm64 gear!
>
> https://docs.google.com/document/d/1HxIU_TEBI6xG9jRHlr8rzyyxFEN43zMcJXUFlRuhiUI/edit#heading=h.bpvv3vr500nw
I'm really
A huge thanks to dave seddon for buckling down and doing some comprehensive
testing of a variety of arm64 gear!
https://docs.google.com/document/d/1HxIU_TEBI6xG9jRHlr8rzyyxFEN43zMcJXUFlRuhiUI/edit#heading=h.bpvv3vr500nw
--
Oct 30:
25 matches
Mail list logo
