UDP Speed Test Version 2.93 Now Available ! - TCP-IP

This is a discussion on UDP Speed Test Version 2.93 Now Available ! - TCP-IP ; I think the difference between operating on the lock's own data, or trying to operator on some user data is minimal to non-existent. Either way, the code you should me is "spinning until it succeeds". The only little difference is ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 69 of 69

Thread: UDP Speed Test Version 2.93 Now Available !

  1. Re: UDP Speed Test Version 2.93 Now Available !

    I think the difference between operating on the lock's own data, or trying
    to operator on some user data is minimal to non-existent.

    Either way, the code you should me is "spinning until it succeeds".

    The only little difference is that the code you showed me incremented
    multiple counters and then finally it examined a big "whole" thing.

    Once it figured out the whole thing was valid it did a swap.

    I mimicked that behaviour quite accurately in my given example so I believe.

    Each thread operators on it's own copy, and then when it has acquired a lock
    a copy is performed... it's almost exactly the same thing.

    And there are no real performence benefits in that code... very small to
    measure.. nothing earth shattering.

    I don't know yet what windows does in it's critical sections, maybe sometime
    later I examined it in o say visual c.. since I think Delphi does not debug
    into kernel stuff or so... and then I'll have a looksy.

    But I already know it's significantly slower then the manual spinning... at
    least not in my given example.

    Also "locking/spinning/unlocking" on user data makes developing algorithms
    much more complex and then the question becomes is it really worth it ?

    I definetly remain unconvinced

    Nice try though

    Now show me a nice Tsocket class or so with build-in udp and OnReceiveEvents
    or so.. with the wsa stuff "under water/underneath" etc... that could be
    interesting =D

    Bye,
    Skybuck.



  2. Re: UDP Speed Test Version 2.93 Now Available !

    Ok,

    I decided to give it one last try, because all your research must have been
    good for something ?

    So I decided to extend the example with more intensive calculations.

    Instead of just a few counters, ten thousand counters are
    incremented/decremented/copied in the continous-lock-free algorithm as well
    as in the blocking-lock algorithm.

    $ifdefs have been used to easily switch between "Custom TryLock/TryUnlock"
    and "Critical Section TryEnter/Leave".

    This time the benchmarking shows between a 100% and 200% performance
    improvement for the continous-lock-free algorithm which is quite amazing
    since there is some heavy copieing going on... but it's still faster ?!

    Also again this test debunks your theory that "CAS" would be faster than
    Window's Critical Section implementation.

    The Window's Critical Section TryEnter implementation performs better for
    the "Data Producer" and that's what it's ultimately about.. more performance
    for a "data producer"

    Well you can take a look at the results yourself because I copy/pasted them
    into the comments.

    The test was run at full cpu speed. (X2 3800+, For full specs google
    Skybuck's Dream PC for 2006), range/overflow checking off,
    debugging on (probably doesn't have much influence.)

    So my conclusions for now:

    1. Stick with Window's/Delphi's Critical Sections.

    2. Maybe use a continues-locking-free algorithm as demonstrated in the
    example below.

    If UDP Speed Test 2 would benefit from such an algorithm remains to be seen,
    since it doesn't do that much heavy cpu calculations or memory copies... so
    I am still skeptical if it would benefit at all, also I wonder if the gui
    results updating would start to some "stutters/misses of updates".

    // *** Begin of Code ***

    program Project1;

    {$APPTYPE CONSOLE}

    {

    Test Lock Free Idea's

    Version 0.01 created on 19 september 2007 by Skybuck Flying

    Investigate idea to write non locking or lock free code

    Idea is to copy data, modify one copy, while the others remain stable.

    The stable copies are used by those that needed synchronized data.

    This simple benchmark compares my own Locking/Unlocking Techniques against
    CriticalSections.

    I am not yet sure if the locking/unlocking techniques work perfeclty.

    So far I can see one problem: Delphi strings which are copy-on-write which
    might give problems for
    locking/unlocking code/data copies.

    This is where critical section might be safer.

    Benchmark conclusion:

    More or less inconclusive, code performs more or less the same, the critical
    sections probably slightly
    faster because of less code overhead.

    Maybe if the data producer did more complex calculations it might become an
    interesting technique.

    However one thing can clearly be seen if the comments are uncommented.

    The locking/unlocking mechanism is of less quality because the try lock
    might fail and then nothing
    will be updated to the screen !

    }

    {

    Version 0.02 created on 19 september 2007 by Skybuck Flying

    Apperently Delphi 2007 has a new member for TCriticalSection which is not
    that well documented...

    It's probably actually the same as "my" TryLock method lol

    To prove this the code will be replaced with that method to see if it works
    the same

    Yup it works.

    }

    {

    Version 0.03 created on 22 september 2007 by Skybuck Flying

    There was a bug in the previous version, no var parameter used to clear
    the data structures, it didn't matter though Delphi initialized the run
    variables to zero anyway

    For this updated test it does matter since the test is re-run three times.

    I decided to give this one last test.

    This time I use some more counters like ten thousand to simulate more
    intensive computations.

    (I tried to use one million at first but that gave a stack overflow which is
    kinda weird)

    Run counts producer runs
    Run2 counts consumer runs.

    The total number of runs is now calculated as producer runs + consumer runs.

    Before it was only producer runs.

    This might have caused some skewed results ? or maybe only the producer
    matters.

    Whatever the case may be, the results are now significantly different.

    The continues-lock-free based code is much faster than the blocking-locked
    code.

    However the critical section method outperforms the locks methods which
    debunks the theory
    that cas would be faster than a critical section.

    At least for this test.

    CustomLock results:

    program started
    Locked Producer Runs : 647086
    Locked Consumer Runs : 815195
    Locked Total Runs : 1462281
    Critical Producer Runs: 251621
    Critical Consumer Runs: 409901
    Critical Total Runs : 661522
    Producer Performance Improvement: 157.167
    Consumer Performance Improvement: 98.876
    Total Performance Improvement: 121.048
    press enter to repeat test

    Locked Producer Runs : 634840
    Locked Consumer Runs : 832632
    Locked Total Runs : 1467472
    Critical Producer Runs: 256147
    Critical Consumer Runs: 406656
    Critical Total Runs : 662803
    Producer Performance Improvement: 147.842
    Consumer Performance Improvement: 104.751
    Total Performance Improvement: 121.404
    press enter to repeat test

    Locked Producer Runs : 634880
    Locked Consumer Runs : 833190
    Locked Total Runs : 1468070
    Critical Producer Runs: 295832
    Critical Consumer Runs: 360321
    Critical Total Runs : 656153
    Producer Performance Improvement: 114.608
    Consumer Performance Improvement: 131.235
    Total Performance Improvement: 123.739
    press enter to repeat test

    CriticalLock results:

    program started
    Locked Producer Runs : 809866
    Locked Consumer Runs : 638797
    Locked Total Runs : 1448663
    Critical Producer Runs: 275141
    Critical Consumer Runs: 359099
    Critical Total Runs : 634240
    Producer Performance Improvement: 194.346
    Consumer Performance Improvement: 77.889
    Total Performance Improvement: 128.409
    press enter to repeat test

    Locked Producer Runs : 829471
    Locked Consumer Runs : 627433
    Locked Total Runs : 1456904
    Critical Producer Runs: 327321
    Critical Consumer Runs: 317239
    Critical Total Runs : 644560
    Producer Performance Improvement: 153.412
    Consumer Performance Improvement: 97.779
    Total Performance Improvement: 126.031
    press enter to repeat test

    Locked Producer Runs : 810325
    Locked Consumer Runs : 639526
    Locked Total Runs : 1449851
    Critical Producer Runs: 236476
    Critical Consumer Runs: 389277
    Critical Total Runs : 625753
    Producer Performance Improvement: 242.667
    Consumer Performance Improvement: 64.286
    Total Performance Improvement: 131.697
    press enter to repeat test

    }

    {$RangeChecks OFF}
    {$OverflowChecks OFF}

    { $DEFINE CustomLock}
    {$DEFINE CriticalLock}

    uses
    SysUtils,
    Classes,
    Windows,
    SyncObjs;

    // Skybuck's Atomic TryLock Algorithm/Method:
    {$IFDEF CustomLock}
    function TryLock( var ParaLock : LongBool ) : LongBool;
    begin
    result := not LongBool( InterlockedCompareExchange( Integer(ParaLock),
    Integer(LongBool(True)), Integer(LongBool(False)) ) );
    end;

    // Skybuck's Atomic TryUnLock Algorithm/Method:
    function TryUnlock( var ParaLock : LongBool ) : LongBool;
    begin
    result := LongBool( InterlockedCompareExchange( Integer(ParaLock),
    Integer(LongBool(False)), Integer(LongBool(True)) ) );
    end;
    {$ENDIF CustomLock}

    type
    Tcounter = 1..10000;
    TsharedData = record
    mCriticalSection : TcriticalSection; // for critical producer/consumer
    mLocked : LongBool;
    mCounter : array[Tcounter] of integer;
    mRuns : int64;
    mRuns2 : int64;
    end;

    TProducer = class(Tthread)
    private

    protected
    procedure Execute; override;

    public

    end;

    TConsumer = class(Tthread)
    private

    protected
    procedure Execute; override;

    public

    end;

    TCriticalProducer = class(Tthread)
    private

    protected
    procedure Execute; override;

    public

    end;

    TCriticalConsumer = class(Tthread)
    private

    protected
    procedure Execute; override;

    public

    end;

    var
    mProducerCopy : TsharedData;
    mConsumerCopy : TsharedData;
    mSharedCopy : TsharedData;

    procedure TProducer.Execute;
    var
    vCounter : Tcounter;
    begin
    while not Terminated do
    begin
    with mProducerCopy do
    begin
    // lock our memory.
    {$IFDEF CustomLock}
    if TryLock( mLocked ) then
    {$ENDIF}

    {$IFDEF CriticalLock}
    if mCriticalSection.TryEnter then
    {$ENDIF}

    begin
    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mCounter[vCounter] := mCounter[vCounter] + 1;
    end;
    mRuns := mRuns + 1;

    // now try locking the memory of the others which should be updated with
    our data
    // if the lock fails, to bad, do no update, and simply continue with our
    own data.

    {$IFDEF CustomLock}
    if TryLock( mConsumerCopy.mLocked ) then
    {$ENDIF}

    {$IFDEF CriticalLock}
    if mConsumerCopy.mCriticalSection.TryEnter then
    {$ENDIF}

    begin
    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mConsumerCopy.mCounter[vCounter] := mCounter[vCounter];
    end;

    {$IFDEF CustomLock}
    TryUnLock( mConsumerCopy.mLocked );
    {$ENDIF}

    {$IFDEF CriticalLock}
    mConsumerCopy.mCriticalSection.Leave;
    {$ENDIF}
    end;

    {$IFDEF CustomLock}
    TryUnlock( mLocked );
    {$ENDIF}

    {$IFDEF CriticalLock}
    mCriticalSection.Leave;
    {$ENDIF}
    end; // else do nothing
    end;
    end;
    end;

    procedure TConsumer.Execute;
    var
    vCounter : Tcounter;
    begin
    while not Terminated do
    begin
    // Sleep( 1000 );

    with mConsumerCopy do
    begin
    // try to lock our memory
    {$IFDEF CustomLock}
    if TryLock( mLocked ) then
    {$ENDIF}

    {$IFDEF CriticalLock}
    if mCriticalSection.TryEnter then
    {$ENDIF}

    begin

    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mCounter[vCounter] := mCounter[vCounter] - 1;
    end;
    mRuns2 := mRuns2 + 1;

    // unlock it

    {$IFDEF CustomLock}
    TryUnLock( mLocked );
    {$ENDIF}

    {$IFDEF CriticalLock}
    mCriticalSection.Leave;
    {$ENDIF}
    end;
    end;
    end;
    end;

    procedure TCriticalProducer.Execute;
    var
    vCounter : Tcounter;
    begin
    while not Terminated do
    begin
    with mSharedCopy do
    begin
    mCriticalSection.Enter;

    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mCounter[vCounter] := mCounter[vCounter] + 1;
    end;
    mRuns := mRuns + 1;

    mCriticalSection.Leave;
    end;
    end;
    end;

    procedure TCriticalConsumer.Execute;
    var
    vCounter : Tcounter;
    begin
    while not Terminated do
    begin
    with mSharedCopy do
    begin
    // Sleep( 1000 );

    mCriticalSection.Enter;

    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mCounter[vCounter] := mCounter[vCounter] - 1;
    end;
    mRuns2 := mRuns2 + 1;

    mCriticalSection.Leave;
    end;
    end;
    end;

    procedure ClearCopy( var ParaCopy : TSharedData );
    var
    vCounter : Tcounter;
    begin
    with ParaCopy do
    begin
    mLocked := false;

    for vCounter := Low(Tcounter) to High(Tcounter) do
    begin
    mCounter[vCounter] := 0;
    end;

    mRuns := 0;
    mRuns2 := 0;
    end;
    end;

    procedure Main;
    var
    mProducer : TProducer;
    mConsumer : TConsumer;

    mCriticalProducer : TCriticalProducer;
    mCriticalConsumer : TCriticalConsumer;

    begin
    writeln('program started');

    repeat

    ClearCopy( mProducerCopy );
    ClearCopy( mConsumerCopy );
    ClearCopy( mSharedCopy );

    mProducerCopy.mCriticalSection := TCriticalSection.Create;
    mConsumerCopy.mCriticalSection := TCriticalSection.Create;
    mSharedCopy.mCriticalSection := TCriticalSection.Create;

    // perform locked test
    mProducer := TProducer.Create(True);
    mProducer.FreeOnTerminate := false;

    mConsumer := TConsumer.Create(True);
    mConsumer.FreeOnTerminate := false;

    // wait 1 second so program can be loaded
    Sleep( 1000 );

    mProducer.Resume;
    mConsumer.Resume;

    sleep(10000);

    mConsumer.Terminate;
    mProducer.Terminate;

    mConsumer.WaitFor;
    mConsumer.Free;

    mProducer.WaitFor;
    mProducer.Free;

    // perform critical test

    mCriticalProducer := TCriticalProducer.Create(True);
    mCriticalProducer.FreeOnTerminate := false;

    mCriticalConsumer := TCriticalConsumer.Create(True);
    mCriticalConsumer.FreeOnTerminate := false;

    // wait 1 second so program can be loaded
    Sleep( 1000 );

    mCriticalProducer.Resume;
    mCriticalConsumer.Resume;

    sleep(10000);

    mCriticalConsumer.Terminate;
    mCriticalProducer.Terminate;

    mCriticalConsumer.WaitFor;
    mCriticalConsumer.Free;

    mCriticalProducer.WaitFor;
    mCriticalProducer.Free;

    mProducerCopy.mCriticalSection.Free;
    mConsumerCopy.mCriticalSection.Free;
    mSharedCopy.mCriticalSection.Free;

    WriteLn('Locked Producer Runs : ', mProducerCopy.mRuns );
    WriteLn('Locked Consumer Runs : ', mConsumerCopy.mRuns2 );
    WriteLn('Locked Total Runs : ', mProducerCopy.mRuns +
    mConsumerCopy.mRuns2 );
    WriteLn('Critical Producer Runs: ', mSharedCopy.mRuns );
    WriteLn('Critical Consumer Runs: ', mSharedCopy.mRuns2 );
    WriteLn('Critical Total Runs : ', mSharedCopy.mRuns + mSharedCopy.mRuns2 );

    Writeln('Producer Performance Improvement: ', Format( '%13.3n ', [
    ((mProducerCopy.mRuns - mSharedCopy.mRuns) / mSharedCopy.mRuns)*100.0 ] ) );
    Writeln('Consumer Performance Improvement: ', Format( '%13.3n ', [
    ((mConsumerCopy.mRuns2 - mSharedCopy.mRuns2) /
    mSharedCopy.mRuns2)*100.0 ] ) );
    Writeln('Total Performance Improvement: ', Format( '%13.3n ', [
    (((mProducerCopy.mRuns + mConsumerCopy.mRuns2) - (mSharedCopy.mRuns +
    mSharedCopy.mRuns2)) / (mSharedCopy.mRuns +
    mSharedCopy.mRuns2))*100.0 ] ) );

    writeln('press enter to repeat test');
    readln;

    until true=false;

    writeln('program finished');
    end;

    begin
    try
    Main;
    except
    on E:Exception do
    Writeln(E.Classname, ': ', E.Message);
    end;
    end.

    // *** End of Code ***

    Bye,
    Skybuck.



  3. Re: UDP Speed Test Version 2.93 Now Available !

    ["Followup-To:" header set to comp.protocols.tcp-ip.]
    On Sun, 16 Sep 2007 21:40:20 -0700, Chris Thomasson wrote:
    ....
    > I am wondering if the file transfer is similar to an algorithm I proposed a
    > while back:


    > Here is a possible rough outline of a protocol that can use the technique I
    > proposed:
    >
    > http://groups.google.com/group/alt.w...cdc4f266c7f104
    >
    > Any thoughts?


    Yes -- where is your flow control?

    "blast the whole file" over UDP and "send a request to the client
    asking it if it got everything" followed by requests for the missing
    pieces would be horribly inefficient if the server can push a
    gigabit/s [0], but the client is on a home ADSL connection. Only a
    tiny fraction of the datagrams would get through, and the answer would
    be "no" over and over again, until the chunks transferred are small
    enough to go through.

    There is a reason Stevens warns people who think they can beat TCP
    using UDP.

    /Jorgen

    [0] Or just read quickly from disk. If the server's pipe isn't fast
    enough, it may choose to silently drop the packets even before it
    reaches the network interface, making your application think it
    it sends at tremendous speeds.

    --
    // Jorgen Grahn \X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!

  4. Re: UDP Speed Test Version 2.93 Now Available !

    Well,

    I just investigated critical sections on windows/delphi and apperently here
    is what it does more or less:

    ntdll32.RtlEnterCriticalSection:
    7D61F16C 8BFF mov edi,edi
    7D61F16E 55 push ebp
    7D61F16F 8BEC mov ebp,esp
    7D61F171 51 push ecx
    7D61F172 8B5508 mov edx,[ebp+$08]
    7D61F175 56 push esi
    7D61F176 8D7204 lea esi,[edx+$04]
    7D61F179 57 push edi
    7D61F17A 8975FC mov [ebp-$04],esi
    7D61F17D B800000000 mov eax,$00000000
    7D61F182 8B4DFC mov ecx,[ebp-$04]
    7D61F185 F00FB301 lock btr [ecx],eax
    7D61F189 0F92C0 setb al
    7D61F18C 84C0 test al,al
    7D61F18E 0F84C6020000 jz $7d61f45a
    7D61F194 648B0D18000000 mov ecx,fs:[$00000018]
    7D61F19B 8B4124 mov eax,[ecx+$24]
    7D61F19E 5F pop edi
    7D61F19F 89420C mov [edx+$0c],eax
    7D61F1A2 C7420801000000 mov [edx+$08],$00000001
    7D61F1A9 33C0 xor eax,eax
    7D61F1AB 5E pop esi
    7D61F1AC 8BE5 mov esp,ebp
    7D61F1AE 5D pop ebp
    7D61F1AF C20400 ret $0004

    ntdll32.RtlLeaveCriticalSection:
    7D61F1B7 8BFF mov edi,edi
    7D61F1B9 55 push ebp
    7D61F1BA 8BEC mov ebp,esp
    7D61F1BC 57 push edi
    7D61F1BD 8B7D08 mov edi,[ebp+$08]
    7D61F1C0 FF4F08 dec dword ptr [edi+$08]
    7D61F1C3 7521 jnz $7d61f1e6
    7D61F1C5 53 push ebx
    7D61F1C6 56 push esi
    7D61F1C7 C7470C00000000 mov [edi+$0c],$00000000
    7D61F1CE 8D7704 lea esi,[edi+$04]
    7D61F1D1 BB01000000 mov ebx,$00000001
    7D61F1D6 F00FC11E lock xadd [esi],ebx
    7D61F1DA 43 inc ebx
    7D61F1DB 83FBFF cmp ebx,-$01
    7D61F1DE 0F85C0940000 jnz $7d6286a4
    7D61F1E4 5E pop esi
    7D61F1E5 5B pop ebx
    7D61F1E6 33C0 xor eax,eax
    7D61F1E8 5F pop edi
    7D61F1E9 5D pop ebp
    7D61F1EA C20400 ret $0004

    Probably much more instructions than the custom interlock methods... maybe
    the call overhead for the custom interlock methods makes the custom
    interlock methods slower... me not sure.

    Notice the lock instructions in the critical sections. lock btr and lock
    xadd.

    Bye,
    Skybuck.



  5. Re: UDP Speed Test Version 2.93 Now Available !

    Update:

    By inlining the custom locking methods, the code is now as fast as critical
    sections maybe
    even a bit faster.

    // Skybuck's Atomic TryLock Algorithm/Method:
    function TryLock( var ParaLock : LongBool ) : LongBool; inline;
    begin
    result := not LongBool( InterlockedCompareExchange( Integer(ParaLock),
    Integer(LongBool(True)), Integer(LongBool(False)) ) );
    end;

    // Skybuck's Atomic TryUnLock Algorithm/Method:
    function TryUnlock( var ParaLock : LongBool ) : LongBool; inline;
    begin
    result := LongBool( InterlockedCompareExchange( Integer(ParaLock),
    Integer(LongBool(False)), Integer(LongBool(True)) ) );
    end;

    Nice.

    Bye,
    Skybuck.



  6. Re: UDP Speed Test Version 2.93 Now Available !

    For completeness sake here is microsoft's implementation of the compare and
    swap routine:

    kernel32.InterlockedCompareExchange:
    7D4D882C 8B4C2404 mov ecx,[esp+$04]
    7D4D8830 8B542408 mov edx,[esp+$08]
    7D4D8834 8B44240C mov eax,[esp+$0c]
    7D4D8838 F00FB111 lock cmpxchg [ecx],edx
    7D4D883C C20C00 ret $000c

    As far as I can tell, it's necessary for the variable to be on the memory,
    otherwise it would be pointless if it was modified in a register.

    And the parameters are probably located on the stack.

    Bye,
    Skybuck.



  7. Re: UDP Speed Test Version 2.93 Now Available !


    "Skybuck Flying" wrote in message
    news:fda5pt$634$1@news2.zwoll1.ov.home.nl...
    > Well,
    >
    > I just investigated critical sections on windows/delphi and apperently
    > here is what it does more or less:
    >
    > ntdll32.RtlEnterCriticalSection:
    > 7D61F16C 8BFF mov edi,edi
    > 7D61F16E 55 push ebp
    > 7D61F16F 8BEC mov ebp,esp
    > 7D61F171 51 push ecx
    > 7D61F172 8B5508 mov edx,[ebp+$08]
    > 7D61F175 56 push esi
    > 7D61F176 8D7204 lea esi,[edx+$04]
    > 7D61F179 57 push edi
    > 7D61F17A 8975FC mov [ebp-$04],esi
    > 7D61F17D B800000000 mov eax,$00000000
    > 7D61F182 8B4DFC mov ecx,[ebp-$04]
    > 7D61F185 F00FB301 lock btr [ecx],eax
    > 7D61F189 0F92C0 setb al
    > 7D61F18C 84C0 test al,al
    > 7D61F18E 0F84C6020000 jz $7d61f45a


    Also this jump, jumps to some more code, so it could actually execute some
    more code.

    I won't list it here however... it does use compare and swap as well in
    those sections..

    So I have seen enough for now

    Also TryEnter and Enter seem to call the same routine.. maybe the difference
    is just a return value !

    > 7D61F194 648B0D18000000 mov ecx,fs:[$00000018]
    > 7D61F19B 8B4124 mov eax,[ecx+$24]
    > 7D61F19E 5F pop edi
    > 7D61F19F 89420C mov [edx+$0c],eax
    > 7D61F1A2 C7420801000000 mov [edx+$08],$00000001
    > 7D61F1A9 33C0 xor eax,eax
    > 7D61F1AB 5E pop esi
    > 7D61F1AC 8BE5 mov esp,ebp
    > 7D61F1AE 5D pop ebp
    > 7D61F1AF C20400 ret $0004



    > ntdll32.RtlLeaveCriticalSection:
    > 7D61F1B7 8BFF mov edi,edi
    > 7D61F1B9 55 push ebp
    > 7D61F1BA 8BEC mov ebp,esp
    > 7D61F1BC 57 push edi
    > 7D61F1BD 8B7D08 mov edi,[ebp+$08]
    > 7D61F1C0 FF4F08 dec dword ptr [edi+$08]
    > 7D61F1C3 7521 jnz $7d61f1e6


    notice jump here too.. but short jump to here *

    > 7D61F1C5 53 push ebx
    > 7D61F1C6 56 push esi
    > 7D61F1C7 C7470C00000000 mov [edi+$0c],$00000000
    > 7D61F1CE 8D7704 lea esi,[edi+$04]
    > 7D61F1D1 BB01000000 mov ebx,$00000001
    > 7D61F1D6 F00FC11E lock xadd [esi],ebx
    > 7D61F1DA 43 inc ebx
    > 7D61F1DB 83FBFF cmp ebx,-$01
    > 7D61F1DE 0F85C0940000 jnz $7d6286a4

    ^
    however this jump jumps to some more code as well.

    > 7D61F1E4 5E pop esi
    > 7D61F1E5 5B pop ebx
    > 7D61F1E6 33C0 xor eax,eax


    * so no more code.

    > 7D61F1E8 5F pop edi
    > 7D61F1E9 5D pop ebp
    > 7D61F1EA C20400 ret $0004


    Bye,
    Skybuck



  8. Re: UDP Speed Test Version 2.93 Now Available !

    "Jorgen Grahn" wrote in message
    news:slrnffc51r.c76.grahn+nntp@frailea.sa.invalid. ..
    > ["Followup-To:" header set to comp.protocols.tcp-ip.]
    > On Sun, 16 Sep 2007 21:40:20 -0700, Chris Thomasson
    > wrote:
    > ...
    >> I am wondering if the file transfer is similar to an algorithm I proposed
    >> a
    >> while back:

    >
    >> Here is a possible rough outline of a protocol that can use the technique
    >> I
    >> proposed:
    >>
    >> http://groups.google.com/group/alt.w...cdc4f266c7f104
    >>
    >> Any thoughts?

    >
    > Yes -- where is your flow control?

    [...]

    There is none in that description; I never did document any flow-control. I
    did this UDP file-transfer thing as a toy project. IIRC, I did some
    flow-control in an amortized fashion depending on the size of the file being
    transferred.



    > There is a reason Stevens warns people who think they can beat TCP
    > using UDP.

    [...]

    I agree. However, TCP is simply not applicable and/or efficient in all
    areas... For instance, algorithms that can withstand losing some data.
    Streaming stuff; VOIP, ect...


  9. Re: UDP Speed Test Version 2.93 Now Available !

    [forgot to include alt.winsock.programming in by previous follow-up; Sorry!]


    "Jorgen Grahn" wrote in message
    news:slrnffc51r.c76.grahn+nntp@frailea.sa.invalid. ..
    > ["Followup-To:" header set to comp.protocols.tcp-ip.]
    > On Sun, 16 Sep 2007 21:40:20 -0700, Chris Thomasson
    > wrote:
    > ...
    >> I am wondering if the file transfer is similar to an algorithm I proposed
    >> a
    >> while back:

    >
    >> Here is a possible rough outline of a protocol that can use the technique
    >> I
    >> proposed:
    >>
    >> http://groups.google.com/group/alt.w...cdc4f266c7f104
    >>
    >> Any thoughts?

    >
    > Yes -- where is your flow control?

    [...]

    There is none in that description; I never did document any flow-control. I
    did this UDP file-transfer thing as a toy project. IIRC, I did some
    flow-control in an amortized fashion depending on the size of the file being
    transferred.


    > There is a reason Stevens warns people who think they can beat TCP
    > using UDP.

    [...]

    I agree. However, TCP is simply not applicable and/or efficient in all
    areas... For instance, algorithms that can withstand losing some data.
    Streaming stuff; VOIP, ect...


+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4