Hello,
The mail from Paul Stoffregen is a very interesting for me. Thanks!
Here he wrote, that he is thinking about rising buffer size. Yes,
it is clear that this can enhance the speed, but may have
drawbacks in respect with boards that have very few memory. But
depending on the internal code, it can also result into a longer
interrupt disable state and rise other problems.
For my Arduino Due project, I significantly rised buffer sizes and/or the speed for: Ethernet/W5100, SD-card, RingBuffer(Serial), Wire(I2C)
I patched the sources from the Arduino group, but that gives problems on updates.
A very simple solution would be, if the sources of theese
parameters are inclosed in "#ifndef" ... "#endif" and if it would
be possible to overwrite these few parameters by the proper
definitions before including Arduino.h in the header of the main
program source.
The expirenced programmer can do this and the novice user will still have a well working system with traditional values.
Thanks!--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
Hello,
The mail from Paul Stoffregen is a very interesting for me. Thanks!
Here he wrote, that he is thinking about rising buffer size. Yes, it is clear that this can enhance the speed, but may have drawbacks in respect with boards that have very few memory. But depending on the internal code, it can also result into a longer interrupt disable state and rise other problems.
For my Arduino Due project, I significantly rised buffer sizes and/or the speed for: Ethernet/W5100,
High Paul,
No I didn't publish my changes. After the Arduino Due was officially retired, I decide to freeze the software still using 1.6.9. For this version I can give you the changes:
===========================================================================================================
W5100 1.6.9 - Using 14MHz SPI-clock for the W5100
W5100.h: #define SPI_ETHERNET_SETTINGS
ETHERNET_SHIELD_SPI_CS,SPISettings(14000000, MSBFIRST,
SPI_MODE0)
w5100.cpp SPI.setClockDivider(ETHERNET_SHIELD_SPI_CS, 6);
.................................................
Remark: The maximum SPI-speed for the W5500 is 33.3Mhz
(see remark 4 on chapter "5.5.4 SPI Timing" in
the datasheet version 1.0.2), that is 28MHz for the Arduino Due
and NOT more.
===========================================================================================================
Sd2Card 1.6.9 - Using SPI speed of 42MHz! (It does realy
work with the Arduino Due!):
SD.cpp
// On card.init in SD.cpp set the speed to SPI_FULL_SPEED, that is
42MHz =>
boolean SDClass::begin(uint8_t csPin) {
...
return card.init(SPI_FULL_SPEED, csPin) &&
volume.init(card) &&
root.openRoot(volume);
}
-----------------------------------------------------------------------------------------------------------
The application is using a 24kB buffer for reading from the
SD-card.
After reading one block of data of the fle, the handle closed and
reopend to read the next block of the file.
After reading a 24kB block the data are send calling:
"void WebServer::writeP(const unsigned char *data, size_t
length)".
===========================================================================================================
My benchmarks with the above settings downloading a 8361kB-file from the SD-card to my PC using the "Arduino Ethernet Shield R3" with the Arduino Due did show: 79.6kB/s to 82.3kB/s.
That is a test not only of the Ethernet but the complete system from SD-card to the Arduino Due and via the Ethernet interface to my PC.
As a side info (nothing regarding speed:)
I added to missing functions in the Ethernet
driver to get all info's from the interface:
===========================================================================================================
Ethernet 1.6.9 - Missing funtionality: Get MacAddr and the
current DHCP-IP from the W5100:
.................................................
Ethernet.h -> Definition added:
IPAddress dhcpServerIP();
uint8_t * MacAddr();
.................................................
Ethernet.cpp -> Code added:
//
IPAddress EthernetClass::dhcpServerIP() { return
_dhcp->getDhcpServerIp(); }
//
uint8_t * EthernetClass::MacAddr()
{
static uint8_t Mac[6]={0,0,0,0,0,0};
SPI.beginTransaction(SPI_ETHERNET_SETTINGS);
W5100.getMACAddress(Mac);
SPI.endTransaction();
return Mac;
}
===========================================================================================================
It is time for me to change to the current release of the software, after it is clear that the Arduino Due is still supported.
I will do it this weekend and I will look, if I can test your driver and send benchmarks about the W5500.
Thanks Paul
Hi Cristian, hi Paul,
No, I am not working on a driver with the W5500 chip. But when the Aduino team stopped supporting the Arduino Due and the Arduino Ethernet R3 I had to look what to do to still maintain the boards for myself to be sure to keep my Gardenwatering System running over years and bought two W5500-boards and it was clear for me, that I must adapt the W5100 driver. But the world is changing as I see.
For your information I tested my system more precise:
Arduino
Due + Arduino Ethernet Shield R3 running on 14MHz SPI-speed:
(SPI-Clock for SD-Card-i/o: 42MHz)
24kB user buffer: DefaultCmd: 8561653 byte read from SD
in 25809 ms and send to the web in 85885 ms, total=111694 ms
12kB user buffer: DefaultCmd: 8561653 byte read from SD
in 29025 ms and send to the web in 85879 ms, total=114904 ms
6kB user buffer: DefaultCmd: 8561653 byte read from SD
in 35385 ms and send to the web in 85881 ms, total=121266 ms
3kB user buffer: DefaultCmd: 8561653 byte read from SD
in 48149 ms and send to the web in 85684 ms, total=133833 ms
2kB user buffer: DefaultCmd: 8561653 byte read from SD
in 60892 ms and send to the web in 85669 ms, total=146561 ms
1.5kB user buffer: DefaultCmd: 8561653 byte read from SD
in
73414 ms and send to the web in 85766 ms, total=159180 ms
768B user buffer: DefaultCmd: 8561653 byte read from SD in
132406 ms
and send to the web in 85702 ms, total=218108 ms
256B user buffer: DefaultCmd: 8561653 byte read from SD in
351243 ms
and send to the web in 85727 ms, total=436970 ms
Arduino Due + Arduino Ethernet Shield R3 running on 4MHz
SPI-speed:
(SPI-Clock for SD-Card-i/o: 42MHz)
24kB user buffer: DefaultCmd: 8561653 byte read from SD
in 25837 ms and send to the web in 156533 ms, total=182370 ms
12kB user buffer: DefaultCmd: 8561653 byte read from SD
in 29013 ms and send to the web in 156488 ms, total=185501 ms
6kB user buffer: DefaultCmd: 8561653 byte read from SD
in 35465 ms and send to the web in 156422 ms, total=191887 ms
3kB user buffer: DefaultCmd: 8561653 byte read from SD
in 48129 ms and send to the web in 156328 ms, total=204457 ms
2kB user buffer: DefaultCmd: 8561653 byte read from SD
in 60842 ms and send to the web in 156354 ms, total=217196 ms
Arduino Due + Arduino Ethernet Shield R3 running on 14MHz
SPI-speed:
(SPI-Clock for SD-Card-i/o: 21MHz)
24kB user buffer: DefaultCmd: 8561653 byte read from SD
in 42813 ms and send to the web in 85901 ms, total=128714 ms
12kB user buffer: DefaultCmd: 8561653 byte read from SD
in 48067 ms and send to the web in 85854 ms, total=133921 ms
6kB user buffer: DefaultCmd: 8561653 byte read from SD
in 58487 ms and send to the web in 85879 ms, total=144366 ms
3kB user buffer: DefaultCmd: 8561653 byte read from SD
in 79389 ms and send to the web in 85660 ms, total=165049 ms
2kB user buffer: DefaultCmd: 8561653 byte read from SD in
100216 ms and send to the web in 85677 ms, total=185893 ms
It see that the change of the SPI speed for the SD-card from 42MHz to 21MHz results in a speed reduction of around 60% and is somehow as expected also when using a smaller buffer.
The speed of
Ethernet when
changing the SPI speed for the W5500 from 14MHz to 4MHz is more
difficult to
understand. A reduction of the SPI speed by a factor of 3.5
results only in a
speed reduction of only 55%. The size of the buffer has no
effect. May be that the W5500 chip is working better and that
shows the test from Paul or may be that there are problems with
the SPI driver. I am shure you will find it. Good luck!
Using 14Mhz the speed is 97kB/s. Also with standard 4Mhz, I get a speed of 45kB/s using "void WebServer::writeP(const unsigned char *data, size_t length)" of Arduino 1.6.13.
Best Regards
Dieter
--(disclaimer, I'm the original poster) Anyway, the most exciting of that thread (for the impatients) is at the end, where Paul Stoffregenś **suggests a really sensible proposal .I've thought it's a good idea publish his ideas and advices here to agree a -really important- decision involving more people. What do you think? Thanks! -- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc <mailto:developers+unsub...@arduino.cc>.-- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc <mailto:developers+unsub...@arduino.cc>.-- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc <mailto:developers+unsub...@arduino.cc>.-- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc <mailto:developers+unsub...@arduino.cc>.
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
Hi Andrew,
for the SD-card access it is clear, but the speed is okay.
I looked into the Ethernet and Socket driver. The call of "void WebServer::writeP(const unsigned char *data,
size_t length)" results in a multiple byte copy and that is the
reason for the bad speed. This call should directly call the
socket function and use data pointers and should not move any
data.
Best Regards,
Dieter
-- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
-- You received this message because you are subscribed to the Google Groups "Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
This is for information only:
I corrected my user code for the the Ethernet transfer. When calling "void WebServer::writeP(const unsigned char *data, size_t length)" of the WebDuino package the data are internally moved bytewise and a buffer of 32 bytes is used slowing down the Ethernet transfer.
Now I use the call "server.write(pBuf,DataSize);" that nearly directly calls the socket without any byte move. I recalculate the pointer into my 24kB buffer on each call and also the data size limmiting to 1024 byte that the socket use to write to the Ethernet interface. (Using 2kB is a little bit slower for the W5100.)
Now I get the maximum speed achievable with the W5100 under Arduino 1.6.13 for the Arduino Due:
Enhanced version calling "server.write(pBuf,SizeToWrite);" from Webduino without byte move and 1kB blocks writting via Socket call:(I used a 42MHz Spi-clock for the SD-card. With my hardware it works very well. The official settings should not exceed 28MHz. The capacity of the SPI data lines will be too high using the prototyp boards.)
Best Regards,
Dieter
Hi Paul,
Yes, that's right, I am testing only the transmitt performance.
The code is only part of a really big programm, around 256kB self written code and special hardware deveoped. That is a already mentioned garden watering unit, not available at the market today. May be that I try to sell it next year.
Here I had to check also the speed under some circiumctances and
also the speed for download logs and files, but id does give no
upload.
I use the WebDuino library for the lot of web pages and I also integrated some file downloads.
My original code did call "server.writeP(MyBuf, BytesReadChunk);" which results in internal byte transfer into a 32 byte buffer that is finally written to the socket via "send(_sock, buf, size);" where size can up to 2kB for the W5100 but used in this call are only 32 byte.
I changed my code now and calling "server.write(pBuf,WriteDataChunkToEth);". Finally also "send(_sock, buf, size);" is called but now the pointer to the buffer and the size is not altered. This gives the full speed.
As I understand, the socket code uses the hardware support of the CPU and so in running with full speed.
If you have some code that uses WebDuino to download a file, you can integrate the following code and test:
//----------------------------------------------------------------------------------In affect, you can use any code that you have as long as you don't do any byte move for data or deep nested calls and call quickly "send(_sock, buf, size);"
You will get the same results as long as your client PC ist very
powerfull too. (I am using a i7-6700K with the ASUS Z170-A.)
Best Regards,
Dieter
Dieter
> Please hold off merging #2325.
If you'd prefer a more incremental approach that doesn't substantially
change the Ethernet library design, then merge #2325.
* 03/13/2012 1.6.1 Added clearSUBR(), applySUBR() and modified setSUBR() functions
* because of the ARP errata.
* Keep SUBR 0.0.0.0 unless using TCP connect() or UDP sendto()
* Use the SUBN_VAR variable to read the real subnet.
// the ARP errata fix, only relevant to W5100, W5200
static un_l2cval SUBN_VAR; // off-chip subnet mask address - solve Errata 2 & 3 v1.6 - March 2012
void saveSUBR(
un_l2cval * addr /**< a pointer to a 4 -byte array responsible to set the SubnetMask address */
)
{
// write to off-chip subnet mask address - solve Errata 2 & 3 v1.6
// Basically the hardware ARP engine is broken, unless it is set to 0.0.0.0
// so we have to keep it so, unless we're using TCP connect() or UDP sendto()
SUBN_VAR.lVal = addr->lVal;
}
void setSUBR(void)
{
// apply off-chip subnet mask address - solve Errata 2 & 3 v1.6
WIZCHIP_write_buf(SUBR0, SUBN_VAR.cVal, 4);
}
void clearSUBR(void)
{
// clear on-chip subnet mask address - solve Errata 2 & 3 v1.6
WIZCHIP_write_buf(SUBR0, 0x00, 4);
}
void getSUBR(un_l2cval *addr)
{
// get off-chip subnet mask address - solve Errata 2 & 3 v1.6
addr->lVal = SUBN_VAR.lVal;
}
/**
@brief Get Subnet mask of W5100/W5200.
@return Subnet Mask(32bit Address-Host Ordering)
*/
uint32_t GetSubMask(void)
{
uint32_t ip = 0;
#if (_WIZCHIP_ <= 5200)
setSUBR(); // apply subnet mask address - solve Errata 2 & 3 v1.6
#endif
ip = WIZCHIP_read(SUBR0);
ip = (ip << 8) + WIZCHIP_read(SUBR1);
ip = (ip << 8) + WIZCHIP_read(SUBR2);
ip = (ip << 8) + WIZCHIP_read(SUBR3);
#if (_WIZCHIP_ <= 5200)
clearSUBR(); // clear subnet mask address - solve Errata 2 & 3 v1.6
#endif
return ip;
}
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
Paul,
My implementation was quite simple, written in C and derived from the Wiznet drivers. Once it was working for UDP and TCP, on both W5100 and W5200, I didn't test any further.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
My implementation was quite simple, written in C and derived from the BSD Wiznet drivers. Once it was working for UDP and TCP, on both W5100 and W5200, I didn't test any further.
I see your code also waits to zero the subnet mask. According to the Wiznet errata, you'd zero it right after SnCR reads zero/false, which would be at line 224:
https://github.com/feilipu/avrfreertos/blob/master/freeRTOS9xx/lib_iinchip/socket.c#L224
But you've got the subnet clear down at line 238, after waiting for the socket status to change.
Before publishing this on the main branch of my copy of Ethernet, which may or may not someday be adopted as Arduino's official library, I'd really like to create a test which actually reproduces this problem with the old code and confirms the fix is effective.