ok, thanks to David for the nice explanation. I was a little lost! Chris and Simon, thanks too. I will try the 1516 size right away.
I found in the AVR32 datasheet this line: • Automatic Pad and CRC Generation on Transmitted Frames I guess it's what I want, but it doesn't seem intuitive to enable/disable this feature, so I'm wondering if it's what I'm looking for. I will probably try to implement my own memcpy and checksum functions in assembler, but I must say I'm a little scared. The last time I used assembler is like 10 years ago in a simple school project hehe. The other thing I may try in the meantime is to use the LWIP_CHECKSUM_ON_COPY feature, but since I'm using 1.3.2, I will have to do an update and well... Is there a real improvement in using this option? The other thing I tried to enable was the MEM_USE_POOLS, but I can't build my project when set to 1. I get errors in the lwip framework and can't find the reason so far. I must miss something. Thanks! On Wed, Mar 31, 2010 at 2:15 AM, Simon Goldschmidt <[email protected]> wrote: > > Dany Thiffeault wrote: > > oh and Simon, another question. I haven't seen anything about this in > your > > wiki, but are PBUF_POOL_SIZE and PBUF_POOL_BUFSIZE important too? > > Oh, then it seems like I forgot those two: PBUF_POOL_SIZE is the number of > PBUF_POOL pbufs, each with a size of PBUF_POOL_BUFSIZE bytes. > > > I'm trying to put everything as high as possible, but I have linking > > problems because I need to much memory. Could you give me some > suggestions > > on the parameters to choose if I want to send packets of 8k size, or > more, > > Maximum packet size over ethernet will be 1514 bytes, so a > PBUF_POOL_BUFSIZE of 1516 will be enough. However, if you are low on memory, > setting this smaller (e.g. 512 or 256) help to save memory: smaller packets > waste less RAM and larger packets will use a chain of PBUF_POOLs (e.g. eith > 512, a full-sized packet of 1514 bytes will use 3 pbufs) (- this is what > Chris just wrote about). Although the chaining works quite well, there's > still a small performance gain of having the packet in one piece, so maximum > throughput will be achieved with 1516. > > However, there are other places in the stack that have more impact on > throughput, mainly checksum generation/checking and memcpy. These should be > optimized for your architecture. > > Simon > -- > GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! > http://portal.gmx.net/de/go/dsl02 > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
