I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
Is this possible? How?
The alternative is to raise the priority of everything else that
is running. But I haven’t figured out how to increase the
priority of a login shell and I need to be able to remotely login
without waiting for the application(especially when something
is broken).
The long term goal is to replace the flash disk with a hard
disk. But I still want to be able to keep the FTP transfer as
a lower priority background task.
Thanks,
Carlos
Carlos Clarke <carlos@ptdprolog.net> wrote:
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
Is this possible? How?
The alternative is to raise the priority of everything else that
is running. But I haven’t figured out how to increase the
priority of a login shell and I need to be able to remotely login
without waiting for the application(especially when something
is broken).
The long term goal is to replace the flash disk with a hard
disk. But I still want to be able to keep the FTP transfer as
a lower priority background task.
As a quick hack, you could try replacing “ftpd” with a shell
script that starts the real ftpd at a lower priority, by for
example, using “nice -2 ftpd”…
Cheers,
-RK
\
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
In QNX4 try"
slay -P 5 ftpd
you may need to do the same with Soc(l)ket or Tcpip
“Carlos Clarke” <carlos@ptdprolog.net> wrote in message
news:n5j7euk4pnl4iqig4dtllquks4kvetncv5@4ax.com…
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
Is this possible? How?
The alternative is to raise the priority of everything else that
is running. But I haven’t figured out how to increase the
priority of a login shell and I need to be able to remotely login
without waiting for the application(especially when something
is broken).
The long term goal is to replace the flash disk with a hard
disk. But I still want to be able to keep the FTP transfer as
a lower priority background task.
Thanks,
Carlos
Robert Krten <nospam88@parse.com> wrote:
Carlos Clarke <> carlos@ptdprolog.net> > wrote:
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
Is this possible? How?
The alternative is to raise the priority of everything else that
is running. But I haven’t figured out how to increase the
priority of a login shell and I need to be able to remotely login
without waiting for the application(especially when something
is broken).
The long term goal is to replace the flash disk with a hard
disk. But I still want to be able to keep the FTP transfer as
a lower priority background task.
As a quick hack, you could try replacing “ftpd” with a shell
script that starts the real ftpd at a lower priority, by for
example, using “nice -2 ftpd”…
I am not sure inetd could spawn shell script, but you can at least
change inetd.conf like like:
ftp stream tcp nowait root /usr/bin/nice in.ftpd -2 /usr/ucb/ftpd
-xtang
“Carlos Clarke” <carlos@ptdprolog.net> wrote in message
news:n5j7euk4pnl4iqig4dtllquks4kvetncv5@4ax.com…
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
What driver are you using? The 96% is surely used by the
flash disk driver and not by ftpd. Hence depending on the
driver (custom or not) lowering ftpd priority may not make
any difference.
On Thu, 16 May 2002 14:23:31 -0400, “Mario Charest”
<goto@nothingness.com> wrote:
“Carlos Clarke” <> carlos@ptdprolog.net> > wrote in message
news:> n5j7euk4pnl4iqig4dtllquks4kvetncv5@4ax.com> …
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
What driver are you using? The 96% is surely used by the
flash disk driver and not by ftpd. Hence depending on the
driver (custom or not) lowering ftpd priority may not make
any difference.
It’s the Disk on Chip driver. I figure while it’s running it will
consume the cpu but since it is getting fed input in chunks
my main application will not get blocked for long periods
of time. I can live with short interruptions over a long period.
On 16 May 2002 17:36:25 GMT, Xiaodan Tang <xtang@qnx.com> wrote:
Robert Krten <> nospam88@parse.com> > wrote:
Carlos Clarke <> carlos@ptdprolog.net> > wrote:
I’m running a system where I don’t have control over
incoming FTP transfers. A 5 megabyte file gets transmitted
to me several times a day and is written to a flash disk.
This is consuming 96% of the cpu.
I would like to lower the priority of incoming FTP transfers.
As a quick hack, you could try replacing “ftpd” with a shell
script that starts the real ftpd at a lower priority, by for
example, using “nice -2 ftpd”…
I am not sure inetd could spawn shell script, but you can at least
change inetd.conf like like:
ftp stream tcp nowait root /usr/bin/nice in.ftpd -2 /usr/ucb/ftpd
-xtang
This seems like the easiest to do.
I’ll give it a try.
Thanks.
and thanks to R.Krten, Bill Caroselli, and Mario Charest for their
responses also.