<Wanda[cis]>
(was around 1mbps with absolutely no half duplex support)
<whitequark[cis]>
what the heck is a jam signal
altracer[m] has joined #glasgow
<altracer[m]>
in days of CSMA/CD on shared/half-duplex bus, a transmitting station would abort the packet it was sending, by switching to the jam pattern, potentially shorter than remaining bits, to recover faster, when transmitting station hears a different bit pattern than what it transmitted (must be a collision).
<altracer[m]>
I don't understand how a collision is possible if the second station is also waiting for idle link (in slot times). Do they start transmitting an identical packet header? To some broadcast MAC address destination?
<tpw_rules>
wikipedia has some talk about maximum ethernet network length in bit times
<altracer[m]>
In CAN (and I2C/I3C) this is resolved by slow open-drain drivers
<tpw_rules>
so perhaps two stations can decide to transmit without the other hearing the first
<tpw_rules>
simply due to speed of light delay
<altracer[m]>
a hundred meter run of half-duplex at 2e8 speed of e-field is only 5 bit times of 10 MHz
<whitequark[cis]>
there are repeaters
<tpw_rules>
"The maximum allowed diameter of an Ethernet installation is limited to 232 bits" says wikipedia without citation
<tpw_rules>
i think anti-jabber is a separate thing?
<whitequark[cis]>
yeah jabber is unrelated
<whitequark[cis]>
the answer to "what is a jam signal" btw is "it's any 32 bits that are not the CRC of the preceding frame octets
<whitequark[cis]>
"not intentionally the CRC"
omnitechnomancer has joined #glasgow
<omnitechnomancer>
AFAIR the main difference between CSMA/CD and CSMA/CD is that the latter waits for the link to be idle and then begins transmitting assuming it will not collide and then backing off if collision occurs. While the CA variant includes a random delay before transmitting
<omnitechnomancer>
One of those acronyms should be CSMA/CA
<altracer[m]>
so for shortest packet of 64 bytes (256 bits) the transmitting station has to have the opportunity to detect a collision before it sends the valid CRC16 so that it can substitute 0x5555 or 0xaaaa or whatever jam into CRC and everyone else discards the frame for invalid checksum reasons?
<altracer[m]>
ugh 64*8=512
<whitequark[cis]>
that's 512 bits
<omnitechnomancer>
Unless the automotive one changed it the fcs is a crc32
<whitequark[cis]>
andyes
<whitequark[cis]>
automotive ethernet is a PHY only affair
<whitequark[cis]>
it does not dictate in any way what data you transmit and is in fact a drop-in replacement for normal ethernet
<omnitechnomancer>
Then the FCS is a crc32
<whitequark[cis]>
yeah
<whitequark[cis]>
that's why jam is 32 bits
<omnitechnomancer>
It is annoying that the twisted pair modes do not have an explicit end of frame delimiter
<whitequark[cis]>
oh?
<omnitechnomancer>
As far as I understand the end of the frame is detected when the sender stops transmission long enough. But I may be wrong. This is why the IPG is important
<whitequark[cis]>
no
<whitequark[cis]>
the end of frame is detected immediately once the sender stops transmitting. the FCS is just the last 4 bytes
<whitequark[cis]>
the interpacket gap is crucial because the transmitter and receiver may have slightly different clocks
<omnitechnomancer>
It also means that there is a period where you stop transmitting
<whitequark[cis]>
yes, but it doesn't need to be "long enough", it just needs to be one octet long at least, for purposes of end of frame detection
<whitequark[cis]>
"no carrier" is the explicit end of frame delimiter
<whitequark[cis]>
but you wouldn't need to care about the IPG length if all clocks in the system were the same. IPG serves multiple functions
<altracer[m]>
oh the elasticity buffer, the bane of 25 MHz clock mismatch...
<altracer[m]>
Follow-up question. How does jam work for PHY that is attached not via MII, but via OpenAlliance SPI? Would I need to a) listen to Rx DMA SPI values and b) abort Tx DMA SPI and push 32 bits of different than CRC data in case of mismatch?
<whitequark[cis]>
what's OpenAlliance SPI?
<omnitechnomancer>
altracer (@_discord_102082282268934144:catircservices.org) Do you have a specific PHY part in mind?
<altracer[m]>
None of this matters for Glasgow which is concerned with RMII only, I guess.
<omnitechnomancer>
It appears that in such cases the phy contains a MAC as well
<altracer[m]>
How much does ±100ppm (or better) precision of on-Glasgow crystals constrain jumbo packet length (1500..9000) which are not supported per PR description and absence of hyperram?
<altracer[m]>
answer: 20ppm, don't constrain or treatable by increasing MAC side buffers (and IPG)
<altracer[m]>
TIL hubs (140 or 92 bit delay) used to propagate jam but everyone replaced then with switches which have packet memory
<omnitechnomancer>
I wonder if what I was thinking and the minimum ipg at the receiver depends on the mode, as at higher speeds the PCS becomes more complex, so how many octets correspond to ceasing transmission may be different
<altracer[m]>
I'm pretty sure 10Base-Tx transmits silence after packets from when I poked it with a scope. It's 100 and 1000 that keep transmitting scrambled carrier.
<omnitechnomancer>
Indeed
GNUmoon has joined #glasgow
Guest88 has joined #glasgow
Guest88 has quit [Client Quit]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
leper has quit [Read error: Connection reset by peer]
leper has joined #glasgow
naruitech_36862[ has joined #glasgow
<naruitech_36862[>
Could someone tell me how to resolve the missing Python source files of the Glasgow? For example, I got an error when I tried to import a package like this: " import glasgow.hardware.demultiplexer as glasgow_access". Thanks a lot
<whitequark[cis]>
where is this import located? what code are you running?
<naruitech_36862[>
Thank you Catherrine, there are some detailed information may help you to help me out for the troubleshooting or providing the insight. 1. After done the installing to the Glasgow, I used the command "glasgow --version" to verify the success of the installation. 2. I had cloned the Glasgow source code from GitHub and placed the source code in the folder c:\Python313\Lib\site-packages so that the path of all packages can be
<naruitech_36862[>
referenced easily by the system environment variable "path". 3. I have confirmed that all Glasgow sub-modules can be referenced/imported correctly except the pathon source files can not be found, for instance: " import from glasgow.hardware.target import *", "from glasgow.hardware.multiplexe import *r" , etc.
Foxyloxy has quit [Read error: Connection reset by peer]
<whitequark[cis]>
<naruitech_36862[> "Thank you Catherrine, there are..." <- try reinstalling the entire software package from scratch
<whitequark[cis]>
these files are not supposed to exist any more and there should be no references to them
<whitequark[cis]>
it seems like something is outdated somewhere