Hi Guys , Finally got the clarification . We are not behind NAT . I checked myself by injecting some packets and sniffing the packets on the dest host as Michael suggested . I tried the experiment both ways and the no changes in ip address can be seen . I cross verified with our network-admin that those hosts are not behind NAT . So , most likely case for these connection drop-out are 2010/6/9 Michal Nazarewicz <mina86@xxxxxxx>: >> 2010/6/8 Michal Nazarewicz <mina86@xxxxxxx>: >>> If “ifconfig” on one host gives you different IP addresses then the >>> other host see as incoming IP then you are behind NAT. > > query <query.cdac@xxxxxxxxx> writes: >> Sorry , I failed to understand the above statement . But I have >> something in mind , I will try it tomorrow . >> From the source machine , I send a packet to remote host on a >> different network . Now If I capture packet on the remote host and >> it comes out to be different ip address than the source host , then >> probably I am behind NAT. These hosts are having private ip address. > > Yes, that's what I've written. ;) > > You run “ifconfig” an one machine at it will show you what's it's IP > address (there may be several interfaces). Then you connect from this > machine to the other machine and check the source address on the other > machine. Repeat for the other direction even thou, if you actually can > connect from one machine to the other then it is likely that the one you > are connecting to is not behind NAT. > >> These hosts are not providing any Internet service and mainly >> responsible for processing around Gigabits of data . The processing >> continues for around 24 hours , During the processing , it utilizes >> around 100% CPU for around 4 hours and the connection drop happened >> during that time . Not sure what processig goes on during the time >> which takes all the CPU . The user we are talking here is the user >> under whom these processes runs . > > If the processing takes so much time and is so CPU consuming I'd try > running it with nice, ie.: “nice -n 20 process-data” rather then plain > “process-data” command. > > If the dropping in fact happens only while high CPU usage than maybe in > fact it is a culprit. By running the processing via nice it gets lower > priority (so in effect everything else gets higher priority in > comparison). This could help SSH get its desired CPU interval in time. Thanks for this suggestion . But probably , we will not be able to do that . Our application itself is doing ssh to the other host and during high load the ssh connection drops and our application fails. > > -- > Best regards, _ _ > .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o > ..o | Computer Science, Michal "mina86" Nazarewicz (o o) > ooo +--<mina86-tlen.pl>--<jid:mina86-jabber.org>--ooO--(_)--Ooo-- > Thanks Zaman -- To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
