writing much slower than reading...
well, I am working on writing a capture program to do 640x480x12bpp@30fps to a raw disk, but writing to the raw device is SOOO slow... the reason I say it's slow is the fact that it takes 8 times the system time writing than reading... a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm, VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge WinCast/TV Model 61351 B226, 3.3-RELEASE... now the hard disk can push and pull around 20meg/sec w/o any problems.. but when I time the disk I get: $ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048 2048+0 records in 2048+0 records out 134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec) 5.75 real 0.01 user 0.21 sys $ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048 2048+0 records in 2048+0 records out 134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec) 6.28 real 0.00 user 1.68 sys now, why does it cost SOOO much more processing time to write than read?? are there plans to fix this slow down? is it possible? can't we just dma write out of userland since we are blocking on the write? -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
{ Moved to FreeBSD-Questions }
Emm, I want your system. Have you double checked your numbers? They
look a bit high. Here's what I get on a vinum stripe across two 'cudas
on an SMP box:
rsnow@basil% time dd if=/dev/vinum/rstripe of=/dev/null bs=64k
count=2048
2048+0 records in
2048+0 records out
134217728 bytes transferred in 7.938773 secs (16906609 bytes/sec)
0.007u 0.520s 0:07.98 6.5% 73+371k 2+0io 0pf+0w
-Rob
John-Mark Gurney wrote:
>
> well, I am working on writing a capture program to do 640x480x12bpp@30fps
> to a raw disk, but writing to the raw device is SOOO slow... the reason
> I say it's slow is the fact that it takes 8 times the system time writing
> than reading...
>
> a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm,
> VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge
> WinCast/TV Model 61351 B226, 3.3-RELEASE...
>
> now the hard disk can push and pull around 20meg/sec w/o any problems..
> but when I time the disk I get:
> $ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048
> 2048+0 records in
> 2048+0 records out
> 134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec)
> 5.75 real 0.01 user 0.21 sys
> $ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048
> 2048+0 records in
> 2048+0 records out
> 134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec)
> 6.28 real 0.00 user 1.68 sys
>
> now, why does it cost SOOO much more processing time to write than
> read?? are there plans to fix this slow down? is it possible? can't
> we just dma write out of userland since we are blocking on the write?
>
> --
> John-Mark Gurney Voice: +1 408 975 9651
> Cu Networking
>
> "The soul contains in itself the event that shall presently befall it.
> The event is only the actualizing of its thought." -- Ralph Waldo Emerson
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
John-Mark, have you double checked your numbers? I get: rsnow@basil% time dd if=/dev/vinum/rstripe of=/dev/null bs=64k count=2048 2048+0 records in 2048+0 records out 134217728 bytes transferred in 8.096565 secs (16577120 bytes/sec) 0.016u 0.482s 0:08.09 6.0% 73+370k 0+0io 0pf+0w On vinum striped 9.1G 'cudas, SMP. -Rob John-Mark Gurney wrote: > > well, I am working on writing a capture program to do 640x480x12bpp@30fps > to a raw disk, but writing to the raw device is SOOO slow... the reason > I say it's slow is the fact that it takes 8 times the system time writing > than reading... > > a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm, > VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge > WinCast/TV Model 61351 B226, 3.3-RELEASE... > > now the hard disk can push and pull around 20meg/sec w/o any problems.. > but when I time the disk I get: > $ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048 > 2048+0 records in > 2048+0 records out > 134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec) > 5.75 real 0.01 user 0.21 sys > $ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048 > 2048+0 records in > 2048+0 records out > 134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec) > 6.28 real 0.00 user 1.68 sys > > now, why does it cost SOOO much more processing time to write than > read?? are there plans to fix this slow down? is it possible? can't > we just dma write out of userland since we are blocking on the write? > > -- > John-Mark Gurney Voice: +1 408 975 9651 > Cu Networking > > "The soul contains in itself the event that shall presently befall it. > The event is only the actualizing of its thought." -- Ralph Waldo Emerson > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing much slower than reading...
In article [EMAIL PROTECTED]> you write: >well, I am working on writing a capture program to do 640x480x12bpp@30fps >to a raw disk, but writing to the raw device is SOOO slow... the reason >I say it's slow is the fact that it takes 8 times the system time writing >than reading... > >a bit about the system... k6/2-250, 100mhz system bus, pc100 64meg dimm, >VIA MVP3 chipset (IDE DMA enabled), IBM-DPTA-372730 hard disk, Hauppauge >WinCast/TV Model 61351 B226, 3.3-RELEASE... > >now the hard disk can push and pull around 20meg/sec w/o any problems.. >but when I time the disk I get: >$ time dd if=/dev/rwd0s1g of=/dev/null bs=64k count=2048 >2048+0 records in >2048+0 records out >134217728 bytes transferred in 5.747521 secs (23352281 bytes/sec) >5.75 real 0.01 user 0.21 sys >$ time dd if=/dev/zero of=/dev/rwd0s1g bs=64k count=2048 >2048+0 records in >2048+0 records out >134217728 bytes transferred in 6.281820 secs (21366057 bytes/sec) >6.28 real 0.00 user 1.68 sys Try doing `iostat 1' while doing the transfers. This is what I see here: tty da0 da1 da2 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id TEST A:0.00 0 0.00 64.00 119 7.47 0.00 0 0.00 0 0 3 0 97 TEST B:0.00 0 0.00 64.00 419 26.18 0.00 0 0.00 0 0 1 0 99 TEST C:0.00 0 0.00 64.00 95 5.94 64.00 95 5.94 0 0 1 0 99 TEST D: 63.84 338 21.05 64.00 343 21.41 0.00 0 0.00 0 0 26 2 72 TEST A: (writing) dd if=/dev/zero of=/dev/rda1 bs=1m count=400 TEST B: (reading) dd if=/dev/rda1 of=/dev/zero bs=1m count=400 TEST C: (read & write)dd if=/dev/rda1 of=/dev/rda2 bs=1m count=400 TEST D: (read raw & write fs) dd if=/dev/rda1 of=trash bs=1m count=400 System is a Dell Poweredge 4300 PIII/600, all disks are Seagate ST39103LC. Disk da0 (where the trash file is written) has softupdates enabled. This is on a week old -current. I'm suprised by the last line. Writing to the filesystem is faster than writing to the raw device? I must be missing something here. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kstat - an API for gathering kernel stats
On Thu, 4 Nov 1999, Arun Sharma wrote: > On Thu, Nov 04, 1999 at 09:31:02PM -0600, Chris Costello wrote: > > On Thu, Nov 04, 1999, Arun Sharma wrote: > > > Can a loadable module, say a network driver register variables with > > > sysctl ? Can sysctl itself be made a loadable module ? As for the speed, > > > > a.) Yes. > > I don't see any examples in sys/modules. The SYSCTL_INT macros eventually > expands to DATA_SET which puts certain data in a different ELF section. > > In other words, sysctl seems to be relying on physical adjacency of > certain structures after linkage is done. This ELF section is used by the loader to automatically register the sysctl nodes (and unregister them on unload). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kstat - an API for gathering kernel stats
On Fri, 5 Nov 1999, Mike Smith wrote: > > On Thu, 4 Nov 1999, Mike Smith wrote: > > > Sysctl is faster than kstat once you have performed the name->oid > > > lookup. There is basically nothing that kstat can do that sysctl can't > > > do better and faster, apart from lookup-by-name. > > > > Except for dynamic registration right? > > No, Peter fixed that a while back. I changed sysctl to be dynamic about 9 months or so ago. This is only available in -current btw. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Procfs' pointers to files.
David Malone wrote: > > However, procfs currently allows people to do this with an executables > file. You can make hard links to and run /proc/nnn/file as it is > essentially another hard link to the executable file. This could > be a problem if you have suid executables protected by nonexecutable > directories, as people can steal copies of the file while it is > running. > > Is this a real problem, or is it a "well don't protect suid > executables that way" problem? The permissions used in Linux's > /proc seem to be more conservative and seem to prevent this. Err... I don't see the problem. The permissions of the hardlink will be different, so the user might be able to see the "code", but won't be able to run the suid (because the hardlink won't have the suid bit set). As for not seeing the code, "security by obscurity..." -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: exec() security enhancement
Borja Marcos wrote: > > Hello, > > Many security exploits create files in the /tmp directory > and execute them. I think it would be a good idea to add logging > to the to exec_check_permissions() in kern.exec.c so that attempts > to run files from a filesystem mounted as "noexec" can be detected. > > With this measeure, and mounting /tmp as "noexec" some > generic hostile acts (wow, how does it sound! :-) ) could be > detected. [and, as you said, the same goes for nosuid -- and for nodev too] This doesn't enhance security. It enhances auditability. I like this. Add a syslog, and a sysctl to turn it on or off. It seems straight-forward and light-weight. Send the patches. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] What y'all wanna do? Wanna be hackers? Code crackers? Slackers Wastin' time with all the chatroom yakkers? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
