<whitequark[cis]>
after some fiddling with iperf and a minor adjustment to one of the USB stack tunables within glasgow, I think we're getting basically the theoretical maximum bandwidth with UDP transmitting "host -> glasgow -> phy -> cat5"
<whitequark[cis]>
the 96.4 Mbps is counted over 1470 byte payloads, if you correct it to account for everything from preamble to IPG, we're getting about 98.5% utilization
<joshua_>
hm, is this a gigabit PHY or a 10/100 PHY?
<whitequark[cis]>
still with a single threaded python asyncio user-mode network interface driver, using stock cpython 3.12.1 without any tuning, and without even pegging a core! it's sitting at about 60% with the UDP flood
<whitequark[cis]>
joshua_: it's a gigabit phy used in 100 mbit mode
<joshua_>
ahh
<joshua_>
yeah that sounds about as good as you can get
<whitequark[cis]>
you know, people doubt that you can have good performance with python a lot
<Wanda[cis]>
gigabit mode will have ... problems
<joshua_>
hm I see no reason wh
<Wanda[cis]>
namely, I'll have to rip up and reimplement the entire pin request layer in glasgow
<joshua_>
er
<joshua_>
hm I see no reason why it should be impossible to achieve byte moving at decent performance with cpython
<Wanda[cis]>
so that we can stuff DDR buffers on pins
<Wanda[cis]>
(this is fine, we had it planned for a while)
<whitequark[cis]>
joshua_: well, it actually does some processing of the packets! and a syscall per packet! and epoll based wait per packet!
<whitequark[cis]>
and some thread synchronization, and asyncio queueing, and...
<joshua_>
this is the whole thesis behind numpy, anyway, is that the stuff that is expensive to do in python you do not do in python
<whitequark[cis]>
i do it in python tho
<whitequark[cis]>
glasgow doesn't use c extensions
<whitequark[cis]>
(other than libusb)
<joshua_>
I assume you are opaquely manipulating `bytes`, though
<Wanda[cis]>
memoryview mostly, but yes
<whitequark[cis]>
i have a python loop that iterates each packet
<joshua_>
i.e., your python work is O(n) with the number of packets, not the number of bytes
<whitequark[cis]>
joshua_: yes. of course. this and other similar architectural decisions is why it can hit the performance targets it does
<whitequark[cis]>
nevertheless, people doubt that python can do this, and are often off by more than one or two orders of magnitude
<joshua_>
well the dump_hex(packet) seems like it could be slow but the rest of it seems fine, or at least, seems no worse than doing it in any other language
<SnoopJ>
Things Programmers Believe About Python
<joshua_>
I'm not sure how performant `bytes.join` is but that is the kind of thing that could be slow in any language if implemented naively
<joshua_>
but yes, indeed, people do not know what is fast and what is not fast
<joshua_>
this does also do the important thing that the `usb_iface` may get more than one packet per `write()`, so you may be less than one syscall per packet on the 'route to glasgow' side. but syscalls in python should not be any slower than syscalls if you were Writing It In Rust. you're probably spending a handful of clocks that you wouldn't in Rust handling the asyncio dispatch loop but fuck em, computers are fast.
<whitequark[cis]>
it was actually rather less easy to get to this performance point than what you're saying would imply.
<omnitechnomancer>
Time for io_uring
<joshua_>
I mean, I think you did do this quite carefully :) everything seems obvious in retrospect when you have a completed product
<whitequark[cis]>
usb_iface.write also does Very Clever things with USB syscalls, by necessity of it really
<whitequark[cis]>
USB-IF has considered themselves a powerful culture, etc
M87910[m] has quit [Quit: Idle timeout reached: 172800s]
balrog has quit [Ping timeout: 272 seconds]
balrog has joined #glasgow
notgull has joined #glasgow
GNUmoon2 has quit [Ping timeout: 260 seconds]
notgull has quit [Ping timeout: 255 seconds]
GNUmoon2 has joined #glasgow
nyanotech has quit [Read error: Connection reset by peer]
nyanotech has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
Eli2_ has joined #glasgow
Eli2| has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
gundy9558[m] has joined #glasgow
<gundy9558[m]>
Yay!! My glasgow arrived today! The case included! I can't thank esden (@_discord_269693955338141697:catircservices.org) enough for having the tenacity to keep going with the delivery despite all the setbacks. Thanks to everyone else involved too!
<gundy9558[m]>
Now my only problem is I'm buried in work and won't get to look at it until the weekend 😦
<jn>
gundy9558[m]: nice! got any projects/experiments in mind yet?
<theorbtwo[m]>
Hm, just getting to the point of attempting to actually use my Glasgow, and I'm running into a bit of a problem. As far as I can tell, uploading the gateware to the glasgow causes the device to reset, which makes the OS reenumerate it, which causes a LIBUSB_ERROR_PIPE. Windows 10 system, which I suspect has a lot to do with it. (Backtraces available on request, happens even with nothing plugged in but USB... er, and do I need to use
<theorbtwo[m]>
a nopaste site here, or can I just paste it in?)
<gundy9558[m]>
Well, I guess the first step will be to learn amaranth and play with some of the existing applets. I thought maybe I could go through my junk drawer and see if I've got anything halfway interesting that I could try writing an applet for. Maybe something retro computing related, maybe something audio, maybe helping to subvert the intended purpose of something.. not really sure yet.
<jn>
paste sites are everywhere, but AFAIK none is specifically tied to this channel. just use any random one.
<jn>
(oof, got confused for a long moment, because you two spoke interleaved and with nicks of the same length, which i couldn't quickly tell apart with a lazy look)
<theorbtwo[m]>
Hm. OK, now I've got a different, and more worrying problem. The device boot-loops without ever being enumerated by the host, so far as I can tell. It briefly is at PWR plus very faint ACT, then goes to PWR+FX2+ACT, stays there for about 5 seconds, then reboots.
josuah has joined #glasgow
galibert[m] has joined #glasgow
<galibert[m]>
power issues?
<ari>
esden[m]: btw, would it be possible to buy an extra set of probe cables? i would like to buy one for the old glasgow of mine i'm donating to the local hackerspace now
<theorbtwo[m]>
galibert: same cable and computer as was previously working.
<theorbtwo[m]>
Hm, contrarywise, it works on a linux pc.
<sorear>
if you send something that's too long for IRC but not too long for Matrix, the bridge will automatically turn it into a paste
<theorbtwo[m]>
Ah, thank you, sorear! I am, in fact, using the bridge.
<whitequark[cis]>
<theorbtwo[m]> "Hm, just getting to the point of..." <- that should not be happening as you are describing. you should post a log with max verbosity (glasgow -vvv)
<whitequark[cis]>
<theorbtwo[m]> "Hm. OK, now I've got a differen..." <- that sounds like a hardware issue to me
<_whitenotifier-6>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-557-71958094445a0f1dded4bb5908f19f8918196c7c - https://github.com/GlasgowEmbedded/glasgow