Re: [fossil-users] fossil up trunk repo times

2016-07-15 Thread sean farrell 
On Wed, Jul 13, 2016 at 02:52:53PM -0700, jungle Boogie wrote:
> On 13 July 2016 at 12:52, jungle Boogie  wrote:
> >
> > Here's me doing a simple fossil up trunk on machine A:
> 
> 
> What I've done:
> -brought all three machines up to the same fossil version
> -installed tcpdump from source
> -ran packet capture on machine A and the VPS
> 
> On machine A, there's 8 packets totaling 24 seconds. If I'm reading
> wireshark correctly, they are the same packet over and over-- tcp
> retransmission.
> 
> Packets 1-9 are using ipv6 and then the rest (10-20), use ipv4.
> 
> First packet: 2016-07-13 14:29:38
> Last packet: 2016-07-13 14:30:54
> Elapsed: 00:01:15
> 
> 
> On machine B, the entire capture is only 11 packets and completes as
> quickly as I would expect with no changes:
> First packet: 2016-07-13 14:36:12
> Last packet: 2016-07-13 14:36:13
> Elapsed: 00:00:00
> 
> 
> Maybe it's some firewall issue on machine A...
> 
> 

Turns out that it's not a firewall issue on either end. Also, the
repeated ipv6 packets total nearly 1 minute, not 24 seconds like I
originally thought.

Well this isn't fossil specific anymore so I'll be quiet now.

Thanks!

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil up trunk repo times

2016-07-13 Thread jungle Boogie 
On 13 July 2016 at 12:52, jungle Boogie  wrote:
>
> Here's me doing a simple fossil up trunk on machine A:


What I've done:
-brought all three machines up to the same fossil version
-installed tcpdump from source
-ran packet capture on machine A and the VPS

On machine A, there's 8 packets totaling 24 seconds. If I'm reading
wireshark correctly, they are the same packet over and over-- tcp
retransmission.

Packets 1-9 are using ipv6 and then the rest (10-20), use ipv4.

First packet: 2016-07-13 14:29:38
Last packet: 2016-07-13 14:30:54
Elapsed: 00:01:15


On machine B, the entire capture is only 11 packets and completes as
quickly as I would expect with no changes:
First packet: 2016-07-13 14:36:12
Last packet: 2016-07-13 14:36:13
Elapsed: 00:00:00


Maybe it's some firewall issue on machine A...



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil up trunk repo times

2016-07-13 Thread jungle Boogie 
Hi All,

I have a repo hosted at digital ocean and some machines at home have
the same repo and I update them occasionally.

I've noticed one machine takes an incredibly long time to get updates.


Here's me doing a simple fossil up trunk on machine A:
% time fossil up trunk
Autosync:  http://u...@example.com/repo
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 346  received: 715  ip: 1.2.3.4
---
checkout: 5bf63bde0dad962d56fa49f060a0e6e3e9abe9f1 2016-07-13 06:04:40 UTC
tags: trunk
comment:  updated pathogen with latest (user: personA)
changes:  None. Already up-to-date
1:15.53 real, 0.034 user, 0.017 sys;  page: 0 hard/868 soft, swap: 0, I/O: 0/72
Mem: 11124KB (2611KB shared + 138KB data/stack = 2749KB), VCSW: 79 IVCSW: 24



Here's the same repo being polled for updates at digital ocean on machine B:
time fossil up trunk
Autosync:  http://u...@example.com/repo
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 348  received: 715  ip: 1.2.3.4
---
checkout: 5bf63bde0dad962d56fa49f060a0e6e3e9abe9f1 2016-07-13 06:04:40 UTC
tags: trunk
comment:  updated pathogen with latest (user: personA)
changes:  None. Already up-to-date
0m00.51s real 0m00.01s user 0m00.01s system



Any advice on what I can do to figure out why machine A takes much
longer than machine B?

Both machines don't have a huge load (practically 0), both are 32bit
with a very recent version of fossil compiled from source.

machine A:
This is fossil version 1.36 [5cdaeb0d82] 2016-06-28 09:10:23 UTC
Compiled on Jun 30 2016 08:37:53 using clang-3.4.1
(tags/RELEASE_34/dot1-final 208032) (32-bit)
SQLite 3.13.0 2016-05-18 10:57:30 fc49f556e4
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (LibreSSL 2.3.6)
TH1_DOCS
TCL (Tcl 8.6.5, loaded TH_OK: 8.6.5)
JSON (API 20120713)
UNICODE_COMMAND_LINE
DYNAMIC_BUILD

machine B:
 fossil version -v
This is fossil version 1.36 [fcfaae37dc] 2016-06-23 07:43:14 UTC
Compiled on Jun 23 2016 19:01:21 using gcc-4.2.1 20070719  (32-bit)
SQLite 3.13.0 2016-05-18 10:57:30 fc49f556e4
Schema version 2015-01-24
zlib 1.2.3, loaded 1.2.3
SSL (LibreSSL 2.4.2)
JSON (API 20120713)
UNICODE_COMMAND_LINE
DYNAMIC_BUILD

Droplet:
% fossil version -v
This is fossil version 1.36 [2dec4bdfcb] 2016-07-09 16:43:52 UTC
Compiled on Jul 11 2016 16:32:13 using clang-3.4.1
(tags/RELEASE_34/dot1-final 208032) (64-bit)
SQLite 3.13.0 2016-05-18 10:57:30 fc49f556e4
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (LibreSSL 2.3.6)
TH1_DOCS
TCL (Tcl 8.6.5, loaded TH_OK: 8.6.5)
JSON (API 20120713)
UNICODE_COMMAND_LINE
DYNAMIC_BUILD


I'll bring all three up to matching versions, but I don't think this
is a fossil version issue. Both machine A and B are behind the same
NAT with 192.168.0.0/24 address and an ipv6 address from the ISP.

Any pointers to decrease the wait time on machine A are appreciated!

Thanks and Best,
sean


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users