Difference between revisions of "Deduplikace"

From VoIPmonitor.org
Jump to navigation Jump to search
(Created page with "use_block mód byl udělán pro zvýšení výkonu v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů pak i ve zpracování v t2 threadech se p...")
 
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
use_block mód byl udělán pro zvýšení výkonu
+
== use_block ==
v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů
+
- mód byl udělán pro zvýšení výkonu
pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok
 
  
use_block tedy navýšil výkon a zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly
+
- v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů, pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok
a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost
 
  
defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní
+
- tedy navýšil se tím výkon a pak zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly,a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost.
a konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem
 
proto se pro use_block mód přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní
 
  
no a podobně se nakonec naložilo s deduplikací
+
Nasel jsem tyto optiony se automaticky nastavuji pri '''t2_boost=yes'''
v use_block módu se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)
 
  
takže ještě jinak v kostce:
+
''opt_enable_process_rtp_packet = 1''
 +
 
 +
''opt_pcap_queue_use_blocks=1 // pokud neni sender, ani scanpcapdir''
 +
 
 +
''opt_process_rtp_packets_hash_next_thread = 2''
 +
 
 +
''opt_process_rtp_packets_hash_next_thread_sem_sync = 1''
 +
 
 +
''opt_preprocess_packets_qring_length = 4 // 3 jen pokud je rucne definovan (process_rtp_packets_qring_length > 2000 || opt_process_rtp_packets_qring_item_length <> 0)''
 +
 
 +
''opt_preprocess_packets_qring_item_length = 5000''
 +
 
 +
 
 +
==udpfrag==
 +
- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?
 +
 
 +
- konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem, proto se pro (pcap_queue_use_blocks = true) přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní
 +
 
 +
==deduplikace==
 +
- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?
 +
 
 +
- pri (pcap_queue_use_blocks = true) se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)
 +
 
 +
 
 +
==shrnuti==
 
- use_blocks mód zvyšuje výkon čtecích threadů
 
- use_blocks mód zvyšuje výkon čtecích threadů
 +
 
- t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód
 
- t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód
 +
 
- bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní
 
- bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní
 +
 
- pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód
 
- pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód

Latest revision as of 19:44, 25 April 2018

use_block

- mód byl udělán pro zvýšení výkonu

- v něm se načtené pakety ukládají do předalokovaného bloku pro více paketů, pak i ve zpracování v t2 threadech se pracuje s ukazatelem na ten jeden velký blok

- tedy navýšil se tím výkon a pak zanedlouho se dělaly optimalizace v t2 threadech, které taky nějaké úspory přinesly,a protože se zdálo zbytečné aby ty dva optiony byly odděleny, zapíná se to dohromady přes option t2_boost.

Nasel jsem tyto optiony se automaticky nastavuji pri t2_boost=yes

opt_enable_process_rtp_packet = 1

opt_pcap_queue_use_blocks=1 // pokud neni sender, ani scanpcapdir

opt_process_rtp_packets_hash_next_thread = 2

opt_process_rtp_packets_hash_next_thread_sem_sync = 1

opt_preprocess_packets_qring_length = 4 // 3 jen pokud je rucne definovan (process_rtp_packets_qring_length > 2000 || opt_process_rtp_packets_qring_item_length <> 0)

opt_preprocess_packets_qring_item_length = 5000


udpfrag

- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?

- konkrétně defragmentace byla problémem, protože by se rozbil koncept předalokovaného bloku načtených paketů - v ní je potřeba pořád nějaké pakety skládat do alokovaných výsledných paketů s celkovým obsahem, proto se pro (pcap_queue_use_blocks = true) přesunula defragmentace až do spojení bloků z více rozhraní - navíc to tedy přineslo možnost defragmentovat obsah z paketů z více rozhraní

deduplikace

- defragmentace a deduplikace se původně pouštěla jen ve čtecích threadech samostatně za každé rozhraní (t0,t1)?

- pri (pcap_queue_use_blocks = true) se deduplikuje i po spojení bloků z více rozhraní (nebo klientů)


shrnuti

- use_blocks mód zvyšuje výkon čtecích threadů

- t2_boost zvyšuje výkon t2 threadů a navíc zapíná use_blocks mód

- bez zapnutého use_block módu není možná defragmentace a deduplikace z více rozhraní

- pokud se zapne auto_enable_use_blocks = yes, zapne si sniffer use_block mód sám, když je požadavek defragmentace nebo deduplikace a je zároveň více rozhraní nebo jde o server/receiver mód