I receive a pcap file of 1.3G, which is the largest package I've ever analyzed.
I try to open it with Wireshark, but even my 7G memory is exhausted, half of the data haven't loaded.
I have to cut it into pieces with editcap command, each piece is either too large or too small:
```shell
#cut every 100000 frame
editcap -c 100000 origin.pcap a.pcap
mkdir pcap && mv a* pcap
```
or
```shell
#cut every 200 second
editcap -i 200 origin.pcap a.pcap #-i means interval
mkdir pcap && mv a* pcap
```
then I try to figure how many block which are found in 4000 second by using such shell script:
```
i=0
for entry in pcap/*
do
tshark -r "$entry" -Y "tcp.len>100 and tcp.dstport==8010" -w "$i.pcap"
i+=1
done
mkdir blocks && mv 0* blocks
```
then I have to merge pcap file with only blocks in it. The mergecap command provide such tool:
```
merge -w blocks.pcap ./blocks/*
```
If you open the blocks.pcap by wireshark, you will see a lot of [TCP previous segment not captured] error,
which will only happen on those TCP stream which mine more than 1 blocks. If a miner only mine a block, he will only send
a package for one time in this pcap, so that the wireshark will not calculate if the sequence number is continous.
In summary, you can neglect the [TCP previous segment not captured] error.
There are 733 segment in blocks.pcap, so 733 blocks were mined in 4000 seconds, which is only 10 percent of the anticipated.
I randomly open a pcap pieced file in pcap folder. I try to use common method to figure out what was happening,such as Steven figure, Expert Info and IO stream. But nothing strange which is anticipated because such problem have been solve previously.
I happen to open the Statics-> Conversation. The strange thing happened:only 1000 tcp conversation were found. But my partner said there are actually 10,000 miner in the program. To figure the actual number of tcp stream in 21 pcap file, I count the SYN+ACk and FIN package respectively.
```
syn=0
fin=0
for entry in pcap/*
do
a=$(tshark -r "$entry" -Y "tcp.flags.syn==1 and tcp.flags.ack==1" | wc -l)
syn=$((syn+a))
b=$(tshark -r "$entry" -Y "tcp.flags.fin==1" | wc -l)
fin=$((fin+b))
done
echo $syn
echo $fin
```
There are 1024 SYN+ACK and 2021 FIN. The FIN number needs to be divide into 2 because half-close of TCP characteristics.
This also explain why only 10 percent of anticipated blocks were mined.
My parnter tell me that it's ascribed to limitation of 1024 file handler owned by a thread.
You can enlarge by this command:
```
unlimit -s 1000000
```