> ~220 MB/s. I'm not sure why you expect this to be a problem.
because of the pci busses, memory etc. it's got to be read and
transmitted. I'll be glad if i don't need to worry
> why? VM in general is designed to have swap. why would it hurt?
well... i thought of potential dropouts... i don't know why... forget it
> neither tux nor sendfile have anything to do with the caching,
> which is done by the kernel (VM and FS readahead, if any).
>
> > sendfile read the file into the cache buffer before sending it? I mean - I
> > can't keep the files in memory, so how much would do?
>
> VM works by scavenging not recently or frequently-used pages.
Does this mean the system could run smoothly on very low memory - say -
128MB RAM?
> > Q: If using the bandwidth control in Tux, how much CPU overhead may I
> > expect per stream (sizes as mentioned above)?
>
> trivial, I expect. after all, each stream has a trivial bandwidth,
> and bandwidth-control just needs to take a few looks at some timer.
> as I recall, tux uses rdtsc in a smart way to avoid gettimeofday
> syscalls.
Good...
> > Q: Do anyone know what SCSI and NIC (1 or 10Gb-Ethernet) that have low or
> > high CPU overhead? I have the impression that there are quite some
> > variations between different drivers. Is this true?
>
> the bsd-ported scsi driver seems to have some religious friction
> with linux, not surprisingly. afaik, all the usual gigE cards are
> roughly equivalent.
Does this mean I can choose whatever gigE card I want?
How about SCSI drivers?
> > Q: Tux has some way of linking IRQs directly to a specific CPU/thread
> > (don't really remember what this was...). What should/could be used of
> > these, or other tuning factors to speed up the server?
>
> depends on the hardware and IO rates. why are you expecting difficulty?
> 220 MB/s is pretty modest.
ok
> > Q: Are there ways to strip down the kernel, as to get rid of everything I
> > don't want or don't need? Could I gain speed on this, or is it just a
> > waste?
>
> silly.
Not silly. I'm not a kernel hacker. I ask naiive questions due to the fact
that I find it better to ask and get to know something, than staying
unknowable of some fact. But thanks for telling me it's of no problem.
> > Q: What file system would be best suitable for this? Ext[23]? ReiserFS?
> > Xfs? FAT? :-)
>
> couldn't possibly make any difference. journalling FS's are only
> valuable because of their crash-robustness in the presence of writes.
> reiserfs is only faster if you have bizzarely skewed file and dir sizes
> (billions of <1K files, billions of dir entries). FAT would be very cool,
> in a retro kind of way, but you'd probably hit file-length limits.
How about XFS? I've heard it's better pushing large files...
> > Q: If using iptables to block any unwanted traffic - that is - anything
> > that's not TCP/80, how much CPU overhead could this generate? Could use of
>
> how much unwanted traffic? why would there be any nontrivial amount?
I thought more about security. I don't want anyone exploiting potential
security holes.
>
> > tcpwrappers or similar systems work better? (I need ssh, snmp and a some
>
> security in depth: use iptables, tcpwrappers, *and* app-based controls.
>
> obviously, iptables discarding any snmp packet from !my.workstation
> is a lot faster than receiving the packet, doing the handshake,
> waking up inetd, firing up tcpd, checking the incoming IP, including
> rev DNS lookups, then passing the socket off to snmp... but it's also
> true that any large amount of bogus packets would be a problem you
> should handle elsehow (ie, DOS attack or serious misconfiguration.)
How about cpu overhead in iptables/kernel when it processes packets that
are allowed? How about connection tracking? Is the rule order in iptables
important when it comes to speed?
I apologize if some of these questions may seem a little stupid. Please do
not flame
Regards
roy
--- Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCAComputers are like air conditioners. They stop working when you open Windows.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:26 EST