Date: Tue, 16 Sep 2014 16:17:20 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Bret Ketchum <bcketchum@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: 9.1 callout behavior Message-ID: <CAJ-Vmom%2BFGB2OCBr9hwvZDL%2B44-fKhM7m97AvCSmN5nB6da%2BhQ@mail.gmail.com> In-Reply-To: <52A731FD.8060307@FreeBSD.org> References: <CAGm6yaTEFECTYVb94A13TaXMPSLtKLpTbw4iNdgd8SuNF1QDaA@mail.gmail.com> <CAJ-Vmokrchy4pXLvZ21sCV09fQUdYKeUYCEH1U1NdfDBxhyJQg@mail.gmail.com> <5295A261.2060403@FreeBSD.org> <CAGm6yaRAPoiVXuv3HgvJCHBTUYGokLyRLb_n0MQEyRp%2BcJUrqA@mail.gmail.com> <CAGm6yaRRcS1e5b_uo4wq=ArSMxFuuTkrKTgOTcQC9nbLnYi6Yw@mail.gmail.com> <529F4409.9080403@FreeBSD.org> <CAGm6yaRFQZ69gQ_Jv0JG5-ru=XtROV5mz7kONC46LRYoe1XTVg@mail.gmail.com> <CAJ-VmonJg-Lsbijc1PnqKt%2BAfmjLxkQpXbKQ4R90bWq7QoXkJQ@mail.gmail.com> <CAGm6yaT=6b6AxDxgivP1jUBmNG1Ynrh58tvhhtZ-qW%2BMKpbj3w@mail.gmail.com> <CAGm6yaSQBVXEQ=8NNLjQ0-1q5jxpBeQT2GCUhhCa4_qqiPX=pQ@mail.gmail.com> <52A1B869.6080407@FreeBSD.org> <CAJ-VmokdyubZLWfp7jub6LqCT%2BZwx0bO4vL6_G3L7CNngcYkQA@mail.gmail.com> <52A21AE9.5020803@FreeBSD.org> <CAJ-VmomRfSG7rXxKMEummRWET1bn_JZ=E7uG-Q1n-_H5NB-r5g@mail.gmail.com> <CAGm6yaRd41fXsFF1OTFyLQq7LAsbnZQ934-zYXNFsuCGCaMQqQ@mail.gmail.com> <52A731FD.8060307@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! I know this is bringing up an old thread, but Dell has shipped us some hardware (thanks Dell!) and I'm helping them take a look at it. On 10 December 2013 07:23, Alexander Motin <mav@freebsd.org> wrote: > On 10.12.2013 17:12, Bret Ketchum wrote: >> >> Do either of you have a dual socket/package motherboard to play >> with? I've tried a couple single socket motherboards and cannot >> reproduce the issue. I'm wondering if this occurs on only multi-socket >> mobos. > > > My main test system is dual-socket (Supermicro X8DTU). It's reasonably reproducable. The tscdrift tool from jhb (in tools/tools/tscdrift) looks thus: root@appollyon:~/src/tscdrift # ./tscdrift CPU | TSC skew (min/avg/max/stddev) ----+------------------------------ 0 | 0 0 0 0.000 1 | 34 79 380 39.005 2 | 306 476 1326 120.472 3 | 306 485 1426 123.487 4 | 280 473 7500 248.965 5 | 280 462 1320 126.691 6 | 300 461 1934 129.362 7 | 300 470 1354 122.654 8 | 292 420 3640 152.029 9 | 135 190 655 58.601 10 | 112 188 620 56.490 11 | 114 189 660 62.440 12 | 129 204 566 53.731 13 | 129 206 617 56.047 14 | 126 211 620 54.450 15 | 126 213 603 54.808 16 | 440 590 1683 217.649 17 | 440 612 1606 234.295 18 | 468 642 4017 266.768 19 | 463 653 8683 352.624 20 | 480 671 1500 255.395 21 | 480 689 8060 348.384 22 | 468 707 3766 296.721 23 | 466 703 1683 284.625 24 | 480 767 8183 373.741 25 | 486 782 7400 362.069 26 | 480 664 1620 249.125 27 | 477 686 3669 278.144 28 | 469 621 1897 226.673 29 | 469 649 8275 363.575 30 | 457 636 1835 250.005 31 | 451 641 4300 272.322 If I modify their supplied ticktock module to call callout_reset_on(args, 0); to call on CPU #0, then it actually doesn't seem to drift. I'm going to look at mav's recent patch to the scheduler in case it has an effect on things. -a
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom%2BFGB2OCBr9hwvZDL%2B44-fKhM7m97AvCSmN5nB6da%2BhQ>