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

Re: Linux packet drops



Hi,

Yes, the issue is not to do with any particular disk. The reason might be 
due to the interrupt dtriven I/O.
Whenever a disk read or write is made, it interrupts the OS for every byte 
of its read or write, which could be a reason for stalling the process & 
hence a packet corruption.

Reduction in the CPU usage might also help due to the shorter duration 
memory & I/O cycles. Bus clock speed is another area that can be looked 
into, but I don't think that it might be a matter of concern in this case.

Regards,
--
Hari
http://hari.accosted.net

On 6/21/05, Sonali Gupta <sonali25 gmail com> wrote:
> 
> Hi,
> 
> We are using Snort on Linux in the binary packet capture mode (capture
> and log in tcpdump format). We find packet drops even at 5 Mbps
> bandwidth which we feel is very low for the hardware we are using. We
> would be grateful if you can provide any suggestions on the issue.
> 
> Hardware used:
> HP Proliant DL 140 G2. Dual processor, processor speed 2.8 GHz with
> 512MB RAM and 72 GB SATA HDD, Gigabit network card.
> 
> Operating system: Red Hat Enterprise Linux ES Version 3.
> 
> Snort version: Snort 2.3.0
> 
> The OS is a default installation. We are not running any software
> other than snort on the system.
> 
> Observations:
> We find that the drop is related to HDD writes.
> 
> If there are no hard disk writes, then there is no drop even at 80
> Mbps. We tested this by using a rule in snort which rarely matches, so
> that snort hardly logs any packets.
> 
> We also found that the drop increases when the I/O is high,
> irrespective of whether it is being done by the same process (snort)
> or a totally unrelated one. We created a high I/O scenario by doing
> copy of a huge file (3GB) periodically while snort is running. Even
> this triggered packet drops.
> 
> So, to summarize, we see packet drops in sniffing whenever there is
> disk I/O happening.
> We do not suspect the HDD of the machine, as we were able to simulate
> the problem in two other totally different systems also.
> 
> Regards,
> Sonali
> 
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request redhat com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>


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