[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CPU for firewall machine?



In a message dated 8/10/00 9:27:30 PM Eastern Daylight Time, rbrito@iname.com 
writes:

> Two or three hours ago, I had to transfer a CD image between
>   two machines of mine and both of them are using el-cheapo
>   10mbps ISA cards. I started the transfers using NFS but after
>   I saw that it would take my entire life for the transfer to be
>   finished, I simply installed Apache on the serving side and
>   used wget to pull the file.  Whoa, I visibly got much better
>   transfer rates and wget, at the final of the transfer said it
>   got 400MB+ with a transfer rate of 915.xx KB/s, which is much
>   more than 5mbps. This obviously doesn't count the overhead
>   incurred by the TCP/IP protocols.
>  
>   So, this means the 486 might be subject to more than 5mbps.
>   But I still believe it can handle it, depending on the needs
>   of the network and pattern of usage.

Are we overlooking any cpu time traded for compression/decompression for the 
smaller amount eventually sent?

Infotel has scsi cards down below 25$ ISA.  For $50 you can get one w/a bios 
for over 1024 cyls; over 2 disks, etc.  The isa scsi ethernet cards should be 
in same $ range.  Then you can put 2 ethernet cards on scsi bus (just don't 
let'em know about each other, or a "bridged" connection can leap from one to 
the other w/o checking w/OS/cpu).

But, as stated in thread, don't even think about (allow any) disk latency for 
the firewall, logging can be niced/compressed thereon to be sent out to 
bigger box (w/appropriate transaction processing assurances of accurate true 
receipt etc.) and disks become a non-issue (firewall effectively is diskless, 
disks only buffer outbound logs data or participate in pipeline of it; 
logging records created/dispatched to i/o>file/pipeline done in kernal 
space-time of firewall/OS/Server processes; you're just transmitting log 
files to someplace else where they "fit" better; having dealt 
w/log-entry/transmit concurrency; try simple/small obvious/flagged overlap & 
just start each log transmit confirm by looking from bottom end for overlap 
mark/timestamp match true&accurate transfer confirm - else loop for 
retran-try-till-alarm).

Sorta.

Regards,

Jim Cunningham at "home"

If you can't remember it ... ... ... forget it.



Reply to: