Hello,
I have to copy 50 to 100 MByte between nodes from a C programm (using
Quantum C). With fread/frwrite (or read/write) it is between 60 and 80 %
slower then a “cp x y” on the shell. Using buffers and other “tuning”
doesn’t help. It seems, that the C runtime system has a problem if you are
going over the net. A local copy is as efficent as the cp command of the
shell.
I want try to “talk” directly with FSYS on the other node, but I have not
found any documentation for FSYS. Has anybody a sample on doing this? Or the
source of the cp command (hint to QNX Software Systems …)?
Greetings
Holger Arndt
PS: Using system(“cp x y”) is not an option.
Previously, Holger Arndt wrote in comp.os.qnx:
Hello,
I have to copy 50 to 100 MByte between nodes from a C programm (using
Quantum C). With fread/frwrite (or read/write) it is between 60 and 80 %
slower then a “cp x y” on the shell. Using buffers and other “tuning”
doesn’t help. It seems, that the C runtime system has a problem if you are
going over the net. A local copy is as efficent as the cp command of the
shell.
I want try to “talk” directly with FSYS on the other node, but I have not
found any documentation for FSYS. Has anybody a sample on doing this? Or the
source of the cp command (hint to QNX Software Systems …)?
I’m quite sure that cp uses POSIX I/O. You might want to try using
read() and write() and adjusting the buffers. Larger buffers are usually
better, however there might be a more complex interaction due to the size
of an Ethernet packet.
Mitchell Schoenbrun --------- maschoen@pobox.com
Buffers that are too large can work against you. In a single threaded model
both system’s Fsys can act as anoth
–
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010331040311.2739A@node1…
Previously, Holger Arndt wrote in comp.os.qnx:
Hello,
I have to copy 50 to 100 MByte between nodes from a C programm (using
Quantum C). With fread/frwrite (or read/write) it is between 60 and 80 %
slower then a “cp x y” on the shell. Using buffers and other “tuning”
doesn’t help. It seems, that the C runtime system has a problem if you
are
going over the net. A local copy is as efficent as the cp command of the
shell.
I want try to “talk” directly with FSYS on the other node, but I have
not
found any documentation for FSYS. Has anybody a sample on doing this? Or
the
source of the cp command (hint to QNX Software Systems …)?
I’m quite sure that cp uses POSIX I/O. You might want to try using
read() and write() and adjusting the buffers. Larger buffers are usually
better, however there might be a more complex interaction due to the size
of an Ethernet packet.
Mitchell Schoenbrun --------- > maschoen@pobox.com
Buffers that are too large can work against you. In a single threaded model
both system’s Fsys can act as another thread doing both read ahead and write
behind. But if your buffer size is too large you will loose that benefit.
I’ve pumped a lot of data through Fsys and Net. The benefits of going
larger than 8 KB are nill (assuming sequential reads and writes). I would
stick with about 8 KB.
–
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010331040311.2739A@node1…
Previously, Holger Arndt wrote in comp.os.qnx:
Hello,
I have to copy 50 to 100 MByte between nodes from a C programm (using
Quantum C). With fread/frwrite (or read/write) it is between 60 and 80 %
slower then a “cp x y” on the shell. Using buffers and other “tuning”
doesn’t help. It seems, that the C runtime system has a problem if you
are
going over the net. A local copy is as efficent as the cp command of the
shell.
I want try to “talk” directly with FSYS on the other node, but I have
not
found any documentation for FSYS. Has anybody a sample on doing this? Or
the
source of the cp command (hint to QNX Software Systems …)?
I’m quite sure that cp uses POSIX I/O. You might want to try using
read() and write() and adjusting the buffers. Larger buffers are usually
better, however there might be a more complex interaction due to the size
of an Ethernet packet.
Mitchell Schoenbrun --------- > maschoen@pobox.com