Forgot your password?
typodupeerror

Comment: Network won't be your bottleneck. (Score 5, Informative) 517

by m0e (#26139421) Attached to: SoHo NAS With Good Network Throughput?

Disk will always be. Since disk is your slowest spot you will always be disk I/O bound. So in effect there's no real reason to worry about network throughput from the NIC. NICs are efficient enough these days to just about never get bogged down. What you would want to look at for the network side would be your physical topology -- make sure you have a nice switch with nice backplane throughput.

About disks:

Your average fibre channel drive will top out at 300 IO/s because few people sell drives that can write any faster to the spindle (cost prohibitive for several reasons). Cache helps this out greatly. SATA is slightly slower at between 240-270 IO/s depending on manufacturer and type.

Your throughput will depend totally upon what type of IO is hitting your NAS and how you have it all configured (RAID type, cache size, etc). If you have a lot of random IO, your total throughput will be low once you've saturated your cache. Reads will always be worse than writes even though prefetching helps.

If you're working with multi-gigabyte datasets, you'll want to increase the number of spindles (ie number of disks) to as high as you can go within your budget and make sure you have gobs of cache. If you decide to RAID it, which type you use will depend on how much integrity you need (we use a lot of RAID 10 with lots of spindles for many of our databases). That will speed you up significantly more than worrying about the NICs throughput. don't worry about that until you start topping a significant portion of your bandwidth -- for example, say 60MB/sec sustained over the wire.

This doesn't get fun until you start having to architect petabytes worth of disk. ;)

Comment: Re:Neutrality (Score 1) 413

by m0e (#25580371) Attached to: Sprint Cuts Cogent Off the Internet

Tier-1/2 transit providers have been depeering and blackholing each other since the the Internet's infancy. Sometimes over as little as a squabble between the two companys' engineers. Usually it gets resolved quickly ($$$). Sometimes it doesn't. Seems like a stupid thing to do IMO since it is doing nothing but hurting their customers.

[SprintCust] Hey, we can't get to (insert CompanyB web application -- important to SprintCust's business)
[SprintCust] *calls up CompanyB* Hey, is your application down? We're trying to do our business with you but we can't and we're losing a lot of money
[SprintCust] ...
[SprintCust] ...it's because of WHAT?
[SprintCust] FUCK SPRINT

Then multiply that by a number whose product will cause the irritation of some upper managers and this will finally end -- they'll at least route traffic to them if they don't re-peer. (in theory -- i never said Sprint was a rational company)

If you have to ask how much it is, you can't afford it.

Working...