egg|anbo|egg_ has quit [Remote host closed the connection]
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg__ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 268 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
egg|anbo|egg_ has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
redstarcomrade has joined #glasgow
geekcowboy has joined #glasgow
geekcowboy_ has quit [Ping timeout: 245 seconds]
geekcowboy_ has joined #glasgow
geekcowboy has quit [Ping timeout: 240 seconds]
geekcowboy has joined #glasgow
geekcowboy__ has joined #glasgow
geekcowboy_ has quit [Ping timeout: 252 seconds]
geekcowboy_ has joined #glasgow
geekcowboy has quit [Ping timeout: 240 seconds]
geekcowboy__ has quit [Ping timeout: 252 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #glasgow
geekcowboy has joined #glasgow
geekcowboy__ has joined #glasgow
geekcowboy_ has quit [Ping timeout: 252 seconds]
geekcowboy_ has joined #glasgow
geekcowboy has quit [Ping timeout: 252 seconds]
geekcowboy has joined #glasgow
geekcowboy__ has quit [Read error: Connection reset by peer]
geekcowboy_ has quit [Ping timeout: 252 seconds]
geekcowboy_ has joined #glasgow
geekcowboy has quit [Ping timeout: 240 seconds]
geekcowboy__ has joined #glasgow
geekcowboy_ has quit [Ping timeout: 252 seconds]
egg|anbo|egg has quit [Remote host closed the connection]
geekcowboy__ has quit [Ping timeout: 252 seconds]
geekcowboy__ has joined #glasgow
geekcowboy__ has quit [Ping timeout: 252 seconds]
geekcowboy__ has joined #glasgow
jstein has joined #glasgow
redstarcomrade has quit [Quit: Connection closed for inactivity]
geekcowboy__ has quit [Ping timeout: 252 seconds]
geekcowboy__ has joined #glasgow
GNUmoon2 has quit [Ping timeout: 244 seconds]
geekcowboy__ has quit [Ping timeout: 252 seconds]
<kbeckmann>
is there a way to lower the sample rate when running `glasgow run analyzer`? I keep getting FIFO overrun even when only sampling one pin. I'm on an old RevB.
geekcowboy__ has joined #glasgow
<kbeckmann>
`glasgow run benchmark` gives me around 28 MB/s on all ports of my PC. is that good or bad? I have a vague memory of getting a bit faster transfers than that.
<d1b2>
<Attie> do you have anything else on the bus? (e.g: webcam) and do you have a root port available?
<d1b2>
<Attie> i'm not sure about revB, but revC certainly should exceed ~40MiB/s
<d1b2>
<Attie> (... and I'm not aware of a reason for that to be different)
<kbeckmann>
i connected it directly to the mainboard so that should be fine. i also tried a bunch of different ports.
<kbeckmann>
oh yeah that is definitely faster than my results.
<d1b2>
<Attie> those ports can still share bandwidth with others
<electronic_eel>
could also be a python or libusb issue
<kbeckmann>
i ran it in a loop and disconnected everything including my keyboard. still getting 28 MB/s
<kbeckmann>
yeah perhaps. i'm on archlinux, upgraded recently. running latest main branch of glasgow.
<d1b2>
<Attie> hmm... that's frustrating - thanks for trying though
<kbeckmann>
could be the cable i suppose
<kbeckmann>
let me try with a few different ones
<electronic_eel>
maybe try booting the system with a live linux on usb memory stick and use a different distro. to rule out kernel, python, libusb and so on
<electronic_eel>
but i'd test the cables first...
<whitequark>
kbeckmann: no, because the analyzer does not stream samples
<whitequark>
it uses compression
<kbeckmann>
ah, i see, thanks.
<kbeckmann>
i've now tried 3 different cables in various ports, still getting 28 MB/s. i guess i should try other host machines.
<whitequark>
kbeckmann: why do you believe this is a bandwidth issue?
<whitequark>
it's much more likely a latency spike issue
<whitequark>
Glasgow does not have a lot of on-board FIFO memory, so any latency spikes tend to crash the analyzer
<whitequark>
wait
<whitequark>
please disregard everything i said
<whitequark>
you're using `glasgow run analyzer`, not `glasgow run --trace`
<kbeckmann>
yes that's right
<whitequark>
i'm sorry; i misremembered
<whitequark>
the analyzer applet does stream samples of course
<kbeckmann>
(my reasoning was mostly more MB/s is better)
<whitequark>
or, hm
<whitequark>
i forgot more about how it works than i thought i have
<whitequark>
what do you have connected, electrically?
<kbeckmann>
Nintendo 64 audio dac data
<whitequark>
are any of the pins floating?
<kbeckmann>
so it shouldn't be that much bandwidth
<whitequark>
try `glasgow run analyzer --pull-downs`
<kbeckmann>
yes but not the ones i chose to sample
<kbeckmann>
i am running `glasgow run analyzer --port A -V 3.3 --pins-i 0 dump.vcd`
<whitequark>
oh, okay
<whitequark>
so just one pin, and it's driven by the DUT
<kbeckmann>
i am on a RevB which doesn't have pulls
<electronic_eel>
is the electrical connection sound or could it be that the cables wiggle and sometimes disconnect?
<whitequark>
can you show me the partial trace it writes before overflow?
<kbeckmann>
i used a saleae logic with the same cables and got good data