Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118296
MIME-Version: 1.0
References: <90094848-cf18-1b41-da8d-1abd60461940@gmx.de> <CANLbj-r58+n4e5_pjZKczSWXBcYDSEKaDAmFuue=3bkEnDBZJA@mail.gmail.com>
 <fac85a5873a19b0d789ab24d0dc81de4df14c1d7.camel@cmpct.info>
 <CAOD_yv1nod3i3J7L3tk2Arwqeh9Z5OgSs_hwveSyK8+NhrhSZQ@mail.gmail.com>
 <22c8fe8d-b5f3-7284-eedc-01e5232882b8@gmx.de> <CAJmy8YGJZiU=sCQSm9J1CjJgvzTj53SOBo9GdU2O5SvGQjk-BA@mail.gmail.com>
 <e643e3a5-3635-3897-8c26-63092a935020@gmx.de> <CAJmy8YEOXgeEc0xbqUpXceP0Fc5aZA0AkadyXN=sfskGg_PV5A@mail.gmail.com>
 <2a0ef561-d0fc-62e8-7c79-548ccdb67cb6@gmx.de> <CAJmy8YH-=MuV_WyRO0MZ1RtKrgQBOjhn44+32Wp2g+eeh_ExWg@mail.gmail.com>
 <e2dd7e66-17f9-15ce-a3a5-33308ceb3244@gmx.de> <CAJmy8YHm0_Ch5HkKiaYfuUt4L+3vJRTnzjgSgNJg7nckwcR8Cg@mail.gmail.com>
 <CAJmy8YGH9ESjPbb-KaQOTDpA5x-WZjxgq5jrrx0NC1q41ABw-g@mail.gmail.com> <CAJmy8YEanyV75c=yM3GT-JvmLsj9-c9pUduaCROwaygPSvOqcA@mail.gmail.com>
In-Reply-To: <CAJmy8YEanyV75c=yM3GT-JvmLsj9-c9pUduaCROwaygPSvOqcA@mail.gmail.com>
Date: Sat, 23 Jul 2022 00:42:38 +0200
Message-ID: <CAJmy8YF1ZxsTi=v5FDYPi=4Lk0YpZSMdzJQw7P+2-+g0wOF1Lg@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: james@asgrim.com, Calvin Buckley <calvin@cmpct.info>, 
	Ayesh Karunaratne <ayesh@php.watch>, PHP Developers Mailing List <internals@lists.php.net>, 
	internals-win <internals-win@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000504cbe05e46c8f57"
Subject: Re: [PHP-DEV] Windows PECL build machine died
From: divinity76@gmail.com (Hans Henrik Bergan)

--000000000000504cbe05e46c8f57
Content-Type: text/plain; charset="UTF-8"

.. should have written "making the cpus run hotter and clock lower and
harming single-thread performance without significantly increasing total
throughput, sometimes even harming total throughput" - and making it harder
to see how much *actual* cpu is being used by a process (a process
seemingly using 50% of a physical core might actually be using near 100% of
a core, but you can't see it in htop because HT makes it look like
50%/the-ht-core-looks-ready-to-go-even-if-it-isn't) - comparatively AMD's
SMT seems to nearly always increase total throughput.

On Fri, 22 Jul 2022 at 23:56, Hans Henrik Bergan <divinity76@gmail.com>
wrote:

> 10 days of radio silence? What's going on? anyway benchmarks (countsey of
> bench.sh ) of the server/bandwidth
>
> -------------------- A Bench.sh Script By Teddysun -------------------
>  Version            : v2022-06-01
>  Usage              : wget -qO- bench.sh | bash
> ----------------------------------------------------------------------
>  CPU Model          : Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz
>  CPU Cores          : 40 @ 2524.597 MHz
>  CPU Cache          : 30720 KB
>  AES-NI             : Enabled
>  VM-x/AMD-V         : Enabled
>  Total Disk         : 393.6 GB (48.7 GB Used)
>  Total Mem          : 125.9 GB (12.0 GB Used)
>  Total Swap         : 8.0 GB (0 Used)
>  System uptime      : 10 days, 2 hour 11 min
>  Load average       : 40.18, 40.10, 40.13
>  OS                 : Ubuntu 20.04.4 LTS
>  Arch               : x86_64 (64 Bit)
>  Kernel             : 5.4.0-122-generic
>  TCP CC             : cubic
>  Virtualization     : Dedicated
>  Organization       : AS31798 DataCity
>  Location           : Kitchener / CA
>  Region             : Ontario
> ----------------------------------------------------------------------
>  I/O Speed(1st run) : 812 MB/s
>  I/O Speed(2nd run) : 841 MB/s
>  I/O Speed(3rd run) : 821 MB/s
>  I/O Speed(average) : 824.7 MB/s
> ----------------------------------------------------------------------
>  Node Name        Upload Speed      Download Speed      Latency
>  Speedtest.net    941.15 Mbps       829.87 Mbps         3.09 ms
>  Los Angeles, US  937.01 Mbps       903.15 Mbps         64.21 ms
>  Dallas, US       941.23 Mbps       898.69 Mbps         36.36 ms
>  Montreal, CA     888.80 Mbps       916.91 Mbps         11.09 ms
>  Paris, FR        886.36 Mbps       820.77 Mbps         90.50 ms
>  Amsterdam, NL    854.88 Mbps       770.73 Mbps         98.16 ms
>  Shanghai, CN     426.16 Mbps       833.23 Mbps         216.21 ms
>  Nanjing, CN      439.53 Mbps       542.91 Mbps         198.60 ms
>  Seoul, KR        465.37 Mbps       367.20 Mbps         216.88 ms
>  Singapore, SG    417.93 Mbps       132.76 Mbps         212.71 ms
>  Tokyo, JP        668.62 Mbps       676.35 Mbps         134.48 ms
> ----------------------------------------------------------------------
>  Finished in        : 5 min 35 sec
>  Timestamp          : 2022-07-22 21:35:37 UTC
> ----------------------------------------------------------------------
>
> - it incorrectly says 393GB because of partitioning, it's actually 1TB
>
> - I've intentionally disabled Hyperthreading because... in my
> opinion/experience, hyperthreading implementations in older Intel CPUs
> often did more harm than good, making the cpus run hotter and clock lower,
> this is a (high-end) 2011 model. (I have the opposite experience with AMD
> SMT fwiw)
>
>
>
> On Thu, 14 Jul 2022 at 01:18, Hans Henrik Bergan <divinity76@gmail.com>
> wrote:
>
>> Fwiw Chris Haas / vendiadvertising.com has reached out, they're willing
>> to sponsor raid(1) if my proposal is accepted.
>> Haas is reading this mailing list, but does not wish to participate/post
>> directly at present.
>> (I have no prior relation, never heard of them before today)
>>
>> On Tue, 12 Jul 2022 at 22:31, Hans Henrik Bergan <divinity76@gmail.com>
>> wrote:
>>
>>> i have a 40-core 128GB RAM server with 1 (and only 1) static ipv4
>>> address that I intend to keep around until at least 27 november 2025 (but
>>> unsure after that),
>>> it has more RAM/CPU than i need, and i could set up a virtual machine on
>>> it and give VNC access to the VM in the form of
>>> > ssh -L 9999:localhost:3389 user@ip
>>> then point a RDP/VNC client to localhost:9999
>>> i can dedicate individual TCP ports to it, but not any of 22, 80, 443,
>>> 5900,  5901, 8083, 9999, 587, 2525
>>> (after which i can recommend Teamviewer for a more comfortable access)
>>>
>>> but the server has several caveats:
>>> - it's un-raided, rolling just a single 1TB SSD, if that SSD was to die,
>>> everything on it would be lost, and it would probably take days to replace
>>> the drive.
>>> - it's located in a somewhat unstable environment, occasional power
>>> outage, it was out on 30 june, 23 june, 27 january, and in 2021 was down on
>>> 30 august. (it boots up and recovers automatically, but it has a reboot
>>> time of roughly 300 seconds until ssh responds again)
>>> - I can not offer a dedicated IP (but can offer some dedicated ports)
>>> - May be decommissioned after 27-11-2025
>>>
>>> If that sounds like a good idea, I'll want a ssh public key.
>>>
>>>
>>> On Tue, 12 Jul 2022 at 15:38, Christoph M. Becker <cmbecker69@gmx.de>
>>> wrote:
>>>
>>>> On 11.07.2022 at 21:04, Hans Henrik Bergan wrote:
>>>>
>>>> > Any of you windows.php.net guys familiar with SSH? Can one be
>>>> created?
>>>>
>>>> That would be possible (needed to be set-up by Alex Schoenmaker), but
>>>> while that could solve the upload issue, it wouldn't solve the other
>>>> issue I've mentioned, namely that we need to avoid dynamically linking
>>>> against incompatible versions of dependencies.  And there is yet another
>>>> issue, namely security.  I think these issues can only be solved by some
>>>> central place where the packages are build.
>>>>
>>>> > On Mon, 11 Jul 2022 at 19:52, Christoph M. Becker <cmbecker69@gmx.de>
>>>> wrote:
>>>> >
>>>> >> On 11.07.2022 at 18:53, Hans Henrik Bergan wrote:
>>>> >>
>>>> >>> Is there any SSH public key associated with the Windows php
>>>> developers?
>>>> >> Or
>>>> >>> with CMB?
>>>> >>
>>>> >> No.  At least not regarding windows.php.net.
>>>> >>
>>>> >>> On Mon, 11 Jul 2022 at 18:25, Christoph M. Becker <
>>>> cmbecker69@gmx.de>
>>>> >> wrote:
>>>> >>>
>>>> >>>> On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
>>>> >>>>
>>>> >>>>> Do you mean it is unlikely that Github Actions will suffice?
>>>> because
>>>> >> that
>>>> >>>>> would definitely be a great solution if it was possible/feasible .
>>>> >>>>
>>>> >>>> No.  It is only unlikely that automated uploads to window.php.net
>>>> will
>>>> >>>> ever be possible using GH actions.
>>>> >>>>
>>>> >>>>> Anyway, with regards to "I don't think there are special
>>>> requirements
>>>> >>>>> regarding the hardware", can you give a rough estimate on RAM/disk
>>>> >> space
>>>> >>>>> requirements?
>>>> >>>>
>>>> >>>> The old machine had something like 4 or 8 GB RAM, and a 128 GB hard
>>>> >> disk.
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>

--000000000000504cbe05e46c8f57--