You can directly add the text output of load time...
It is possible to share your pcap ?
On Wed, Dec 2, 2015 at 9:04 AM, POZUELO Gloria (BCS/PSD) <
gloria.pozu...@bics.com> wrote:
> I attach the screen captures better.
>
>
>
> *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-de
I can’t share this one, because it has user data and it’s confidential, but we
are going to generate another one that can be share. We are using GTP protocol,
if that gives you a clue.
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La
I’ve been testing the performance a little more and it seems that the loading
time has increased not only for GTP protocol. I have sniffed a pcap composed by
22844 packets and if you open it up with both versions, v2.0 lasts 0.520s and
v2.1 lasts 1.433s. But as you saw before for GTP protocol is
Hi,
Running valgrind on my standard pcap we have gone from
==36946== Callgrind, a call-graph generating cache profiler
==36946== Copyright (C) 2002-2013, and GNU GPL'd, by Josef Weidendorfer et al.
==36946== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==36946== Command: /
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: den 2 december 2015 15:41
To: Developer support list for Wireshark; alexis.lagou...@gmail.com
Subject: Re: [Wireshark-dev] Wireshark Performance
Hi,
Running valgrind on my sta
The only recent change to conversation_match_exact was the conversion from
address macros to functions, but in all cases the macros were just pointing
to the functions anyways so I can't imagine that would have a huge effect
on performance?
On Wed, Dec 2, 2015 at 9:45 AM, Anders Broman
wrote:
>
Hi,
It’s probably deeper down, dissect_stun_heur has gone from 3.51 to 14.06.
@ Gloria can you try to turn the stun heuristic off to see if it makes a
difference?
Regards
Anders
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus
Sent: de
Where can I find that option?
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: Wednesday 2 December 2015 16:08
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wireshark Performance
Hi,
It’s probably deep
2015-12-02 16:12 GMT+01:00 POZUELO Gloria (BCS/PSD) :
> Where can I find that option?
>
On Windows, Ctrl + Shift + E, or in the menu Analyze -> Enabled protocols.
Unselect stun_udp.
>
>
> *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org] *On Behalf Of *A
Hi,
I’m betting on this change ☺
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=9e54fcee5224aef800155514cac5e40d9e38a23e
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: den 2 december 2015 16:26
To:
Ok, the results seem to be the same
- v2.0: 0.458s.
- v2.1: 7.361s
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin
Sent: Wednesday 2 December 2015 16:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Wiresh
2015-12-02 16:31 GMT+01:00 Anders Broman :
> Hi,
>
> I’m betting on this change J
>
>
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=9e54fcee5224aef800155514cac5e40d9e38a23e
>
This change is also in master-2.0, so it cannot be the culprit.
Pascal.
>
> *From:* wiresha
My current hypothesis is commit 74541a9596eead6647c592de9aa46797c2dffa84
but I don't have any files to test with locally.
On Wed, Dec 2, 2015 at 10:36 AM, Pascal Quantin
wrote:
>
>
> 2015-12-02 16:31 GMT+01:00 Anders Broman :
>
>> Hi,
>>
>> I’m betting on this change J
>>
>>
>> https://code.wire
Does anyone have any experience with EditorConfig
(http://editorconfig.org/)? It seems like it would be useful for getting
rid of our modeline boilerplate, at least in directories where formatting
is consistent.
___
Sent via:
On Wed, Dec 2, 2015 at 6:31 PM, Gerald Combs wrote:
> Does anyone have any experience with EditorConfig
> (http://editorconfig.org/)? It seems like it would be useful for getting
> rid of our modeline boilerplate, at least in directories where formatting
> is consistent.
>
Never try...
but there
On 02-12-2015 17:31, Gerald Combs wrote:
Does anyone have any experience with EditorConfig
(http://editorconfig.org/)? It seems like it would be useful for getting
rid of our modeline boilerplate, at least in directories where formatting
is consistent.
Didn't know about EditorConfig but I thi
On Dec 2, 2015, at 8:11 AM, Evan Huus wrote:
> My current hypothesis is commit 74541a9596eead6647c592de9aa46797c2dffa84 but
> I don't have any files to test with locally.
So that one looks as if it might affect *startup* time but not *file loading*
time.
__
On 02-12-2015 18:41, João Valverde wrote:
On 02-12-2015 17:31, Gerald Combs wrote:
Does anyone have any experience with EditorConfig
(http://editorconfig.org/)? It seems like it would be useful for getting
rid of our modeline boilerplate, at least in directories where formatting
is consisten
> On Wednesday, December 2, 2015 14:09
> On Dec 2, 2015, at 8:11 AM, Evan Huus wrote:
> > My current hypothesis is commit 74541a9596eead6647c592de9aa46797c2dffa84
> > but I don't have any files to test with locally.
>
> So that one looks as if it might affect *startup* time but not *file loading
2015-11-30 20:15 GMT+01:00 Guy Harris :
>
> On Nov 30, 2015, at 11:07 AM, Pascal Quantin
> wrote:
>
>
> > Yes I should have been clearer in my initial description.
> > My suggestion with an extra parameter giving the hash table address is
> also working fine, so I do not have a strong feeling eit
My tests point to v2.1.0rc0-228-g4f39c60 on master as the big one in terms of
capture file load performance hit, but there is an earlier commit that appears
to consistently added one second to the load of my test file versus head on
master-2.0. I'll start bisect for this smaller one shortly.
Figured it out, the macro and the method are not identical. Patch incoming.
On Wed, Dec 2, 2015 at 4:37 PM, Jim Young wrote:
> My tests point to v2.1.0rc0-228-g4f39c60 on master as the big one in terms of
> capture file load performance hit, but there is an earlier commit that
> appears to cons
https://code.wireshark.org/review/12389
A mistake in the macro->method conversion caused the addresses to not
actually be added to the hash, leading to hash collision for most
addresses and the extreme slowdown.
On Wed, Dec 2, 2015 at 4:42 PM, Evan Huus wrote:
> Figured it out, the macro and the
2015-12-02 23:36 GMT+01:00 Jagadeesan, Viswanathan <
vjaga...@qti.qualcomm.com>:
>
>
>
>
> *From:* Jagadeesan, Viswanathan
> *Sent:* Wednesday, December 02, 2015 5:35 PM
> *To:* 'pascal.quan...@gmail.com'
> *Subject:* Question regarding LTE RRC dissectors
>
>
>
> Hi
>
>
>
> followup quest
Le 3 déc. 2015 12:06 AM, "Jagadeesan, Viswanathan" <
vjaga...@qti.qualcomm.com> a écrit :
>
> Hi Pascal
>
>
>
> As know that wire shark call the RRC dissector if packet
has RRC payload of MAC->RLC->PDCP, otherwise it wouldn’t invoke. We need
something like
>
> Ethernet MAC + IP + U
From: Jagadeesan, Viswanathan
Sent: Wednesday, December 02, 2015 5:35 PM
To: 'pascal.quan...@gmail.com'
Subject: Question regarding LTE RRC dissectors
Hi
followup question, it does the creation of dissector dll for RRC
successfully, when it loads on wireshark , it throws a error: "Th
Hi Pascal
As know that wire shark call the RRC dissector if packet has
RRC payload of MAC->RLC->PDCP, otherwise it wouldn’t invoke. We need something
like
Ethernet MAC + IP + UDP + LTE RRC instead of Ethernet MAC + IP + UDP + MAC
+RLC + PDCP +RRC.
Any suggestions.
Thanks,Vis
Thanks.
Exactly we need something. I thought, we can have
The approach:
External plugin register for UDP port 65534
Then Call external RRC dissector.
Your suggestions:
External plugin register for UDP port 65534
Then Call builtin RRC dissector.
I am fine with your approach, any samp
28 matches
Mail list logo
