Has anyone looked into performance improvements? What are the current system bottle necks? What tweaking (if any) is being done with the Windows Registry? What kind of throughput do most people get?
It seems strange to me that the speed of computers running passports would have a strong impact on performance. Is this perhaps related to the fact that the packets are broken up into 50byte increments on TX? This doesn't sound wise since the MAX MTU size for windows is 1500bytes.
Also, I've worked in VoIP, and reducing MTU packet size has a severe impact on throughput of the overall network (even with TCP\IP). (FYI, TDM over IP works best for VoIP, and results in little to no bandwidth lost.)
On the job, I'm working on a wireless modem, and our throughput wasn't all that impressive (100kbit/s) untill we seriously tweaked the windows registry (now we get 400kbit/s). Our max data rate on air is 500kbit/s, yet to date, Windows has been our biggest enemy.
Does anyone out there have some comments (on ideas?) on the Passport's throughput, and what can be done to improve it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>Has anyone looked into performance improvements?
The Help discussion thread has a short exploration of this topic.
>>What are the current system bottle necks?
Parallel port is polled in nibble mode. Making the driver interrupt driven and switching to byte mode can improve performance significantly at the cost of not being able to run on older/not compatible machines.
>>What tweaking (if any) is being done with the Windows Registry?
I would be interested in knowing what kind of tweaking you are talking about.
>>What kind of throughput do most people get?
FTP usually runs between 12 - 14 KB/s.
>>It seems strange to me that the speed of computers running passports would have a strong impact on performance.
Not so strange when you consider the driver is polling the parallel port and disables interrupts when it does the parallel port handshake.
>>Is this perhaps related to the fact that the packets are broken up into 50byte increments on TX?
>>This doesn't sound wise since the MAX MTU size for windows is 1500bytes.
>>Also, I've worked in VoIP, and reducing MTU packet size has a severe impact on throughput of the overall network (even with TCP\IP).
>>(FYI, TDM over IP works best for VoIP, and results in little to no bandwidth lost.)
The powerline environment is very noisy. The underlying physical layer transport sends very small packets to avoid corruption due to noise, so we are forced to segment the packets. It would be nice to work in a cleaner environment.
>>On the job, I'm working on a wireless modem, and our throughput wasn't all that impressive (100kbit/s) untill we seriously tweaked the windows registry (now we get 400kbit/s).
>>Our max data rate on air is 500kbit/s, yet to date, Windows has been our biggest enemy.
Again, I'm interested in knowing what kind of registry tweaks you have done.
>>Does anyone out there have some comments (on ideas?) on the Passport's throughput, and what can be done to improve it?
The PassPort's raw line speed is about 350 Kbaud. The protocol overhead is about 50%, so the theoretical maximum throughput is about 21 KB/s. Some things that will improve the throughput are:
1. Interrupt driven drivers.
2. Byte mode parallel port handshake.
There are probably other tweaks that could be done to the drivers, depending on the OS you are running under. Unfortunately, I'm not a regular driver coder, so I don't have much insight into the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2000-11-11
MTU size sharply affected throughput. (This generally isn't an issue with Linux.) But the network overhead wasn't as high as 50%. i.e. MTU size might get lost in the noise of a high overhead protocol.
I work almost exclusively on embedded device drivers, and I'm just starting to play around with Linux.
Do the existing Pass Port modules support interrupt, byte mode, or would the embedded drivers need to developed as well?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Has anyone looked into performance improvements? What are the current system bottle necks? What tweaking (if any) is being done with the Windows Registry? What kind of throughput do most people get?
It seems strange to me that the speed of computers running passports would have a strong impact on performance. Is this perhaps related to the fact that the packets are broken up into 50byte increments on TX? This doesn't sound wise since the MAX MTU size for windows is 1500bytes.
Also, I've worked in VoIP, and reducing MTU packet size has a severe impact on throughput of the overall network (even with TCP\IP). (FYI, TDM over IP works best for VoIP, and results in little to no bandwidth lost.)
On the job, I'm working on a wireless modem, and our throughput wasn't all that impressive (100kbit/s) untill we seriously tweaked the windows registry (now we get 400kbit/s). Our max data rate on air is 500kbit/s, yet to date, Windows has been our biggest enemy.
Does anyone out there have some comments (on ideas?) on the Passport's throughput, and what can be done to improve it?
>>Has anyone looked into performance improvements?
The Help discussion thread has a short exploration of this topic.
>>What are the current system bottle necks?
Parallel port is polled in nibble mode. Making the driver interrupt driven and switching to byte mode can improve performance significantly at the cost of not being able to run on older/not compatible machines.
>>What tweaking (if any) is being done with the Windows Registry?
I would be interested in knowing what kind of tweaking you are talking about.
>>What kind of throughput do most people get?
FTP usually runs between 12 - 14 KB/s.
>>It seems strange to me that the speed of computers running passports would have a strong impact on performance.
Not so strange when you consider the driver is polling the parallel port and disables interrupts when it does the parallel port handshake.
>>Is this perhaps related to the fact that the packets are broken up into 50byte increments on TX?
>>This doesn't sound wise since the MAX MTU size for windows is 1500bytes.
>>Also, I've worked in VoIP, and reducing MTU packet size has a severe impact on throughput of the overall network (even with TCP\IP).
>>(FYI, TDM over IP works best for VoIP, and results in little to no bandwidth lost.)
The powerline environment is very noisy. The underlying physical layer transport sends very small packets to avoid corruption due to noise, so we are forced to segment the packets. It would be nice to work in a cleaner environment.
>>On the job, I'm working on a wireless modem, and our throughput wasn't all that impressive (100kbit/s) untill we seriously tweaked the windows registry (now we get 400kbit/s).
>>Our max data rate on air is 500kbit/s, yet to date, Windows has been our biggest enemy.
Again, I'm interested in knowing what kind of registry tweaks you have done.
>>Does anyone out there have some comments (on ideas?) on the Passport's throughput, and what can be done to improve it?
The PassPort's raw line speed is about 350 Kbaud. The protocol overhead is about 50%, so the theoretical maximum throughput is about 21 KB/s. Some things that will improve the throughput are:
1. Interrupt driven drivers.
2. Byte mode parallel port handshake.
There are probably other tweaks that could be done to the drivers, depending on the OS you are running under. Unfortunately, I'm not a regular driver coder, so I don't have much insight into the problem.
MTU size sharply affected throughput. (This generally isn't an issue with Linux.) But the network overhead wasn't as high as 50%. i.e. MTU size might get lost in the noise of a high overhead protocol.
I work almost exclusively on embedded device drivers, and I'm just starting to play around with Linux.
Do the existing Pass Port modules support interrupt, byte mode, or would the embedded drivers need to developed as well?
The existing drivers DO NOT support interrupts or byte mode.