How can the Ethernet speed be adjusted or increased using the latest ethernet shield for the Arduino UNO?
Think it through…
The UNO is running at 16MHz,
The shield has a buffer running at some higher rate.
How is the Arduino going to get data out of that buffer any faster - without a higher clock, or DMA on a separate clock ?
Honestly, if the throughput is actually 12Mbit/sec, I think you’re doing pretty well !
I suspect that’s measured with bursts of data smaller than the buffer.size.
In that case, is there a way to make it slower?
Sure, but why…
You only get as much as you need through the interface to the ethernet shield.
If you transact at 1 Byte per second (~10 bits per second), that’s what will go over the network.
To slow down the physical interface itself seems pointless, like using wet string instead of copper wire.
So the only way to speed it up to a full 100 Mbps would require an external clock of at least 100KHz?
Why? Speeding it up is probably impractical / impossible. Slowing it down is a very odd request.
What problem are you trying to solve?
1 Like
It's simply a question rather than a problem that is trying to be solved and last time I checked, this is a learning platform created to LEARN about the product family. It's not odd or "stupid" as your initial response stated before it was edited.
It simply questions why a product that is advertised to operate at a max of 100 Mbps was designed and sold for a microcontroller that has a 16 MHz clock, with no documentation that state the true maximum speed of the device. If anything is "odd" it's that the Arduino group has not upgraded to a much more capable microcontroller in today's modern computing age.
The STM32H7 is not modern enough for you?
That microcontroller is not the one being referenced in this topic. The UNO still uses the ATmega328P which is clearly not on the level of the ARM mcu's you referenced, but thank you for the input
There still is, and always will be a place for lesser featured, lower powered MCU's both in the commercial and hobby market. All the MCU manufacturers offer many, many MCU's that have the same or less performance as the 328. Even now, in 2022.
The market demand for certain Arduinos drives the supply, more so than marketing goals. Arduino does still support the 328 well, but is obviously aware of the need to evolve as embodied in the Nano Every, for example. Many people prefer the 328 for code compatibility reasons.
There is always a need to balance performance with cost. Edit - and power consumption.
Additionally, you say you just wanted to LEARN, and replies were made to answer your question. So that desire was partially fulfilled. I'm not sure people will be very enthusiastic about continuing the discussion after what you have stated, though...
I agree 100%, but in this case, why design an ethernet board for a lesser featured platform that will never be able to support the advertised speeds? There is no problem with a lesser capable platform, but don't design a product for it that it cannot fully support. There should also be far greater transparency to the consumer that explicitly states the limitations of the platform and the products that are designed for it. In my opinion, the ethernet shield should have been a 10-Base T only device, matching the platform it was designed for.
In my opinion, nobody ever thought about the apparent discrepancy between the specification and the actual performance.
Arduino isn't a plug and play consumer device. It's a relatively open ended system of experimental, educational devices. Short of egregious and intentional deception (which the clone makers do indulge in), I don't see much harm in it. You are looking at a technical summary, not a 100 page data sheet. That is where limitations like the one you mention, would often be found.
There may be design reasons why 10/100 hardware was used instead of 10-Base T, beyond the basic speed difference. Also, it's possible that future, faster, Arduinos might achieve the 100 speed with the same shield. So it might not be really a shield problem per se.
Aarg, you are now in charge of adding the STM32H7 to the new UNO board. Make it happen 
I'll be honest - I don't value the shield layout or implementation enough to do that. I actually bought some ESP32 with Uno footprint boards, believing that I could benefit from that, but I found the DIP modules such as the WeMos series more useful in practice.
One big problem, the wholesale conversion of most digital electronics to 3.3V from 5V. It renders a lot of existing shields unusable with newer adaptations like the ESP board I mention. That would be the case with the H7.
1 Like
Likely because 10BT-Only PHYs, MACs, and other components are somewhere between rare and non-existent nowadays. You can buy 10/100 and 10/100/1000 devices for next to nothing. Why would semiconductor manufacturers bother with 10BT-Only? Who would buy it? Just because a given processor can't process full-rate data, why would you throttle speed at the Physical Layer?
There seems to be a disconnect about how the ethernet operates. There is the physical layer, as mentioned. Then there is the transport level which has a lot of overhead in taking care of all the stuff that can and does happen to the network.
The data that is placed on the transport level is what your Arduino or computer or router or whatever is in addition to the network overhead. The actual data movement can never come close to the physical layer speed.
Similar to data transmission at 2.4 gHz. Can never come close to a bit rate of 2.4 gHz.
the bottleneck is the SPI communication. you can set the SPI clock frequency in the library in utils/W5100.h in SPI_ETHERNET_SETTINGS
you can get faster speed with buffering. with less protocol overhead for the SPI communication (and TCP/IP too).
1 Like
network speed and buffer transfer aren't the same think. don't you want the network speed to be compatible with other devices? you don't want to force all devices to run a 1Mbps
Same difference. 100mBPS Ethernet is the clock speed, not the bandwidth.
100 mBps is hardly the same a 2.6 gHz of 5 gHz.
yes your right that the channel bandwidth of 22 mHz is not not the bit rate