FTP och Gbit

Tunnt med info för att ge några konkreta förslag.
Klarar din andra part av att skicka/ta emot snabbare?
Är din motpart Bahnhof kanske?
Wifi?
VPN?

Vad är det som felar då. Hastigheten från Comhem till dig eller från dig till Comhem?
PiHole påverkar inte det.

klarar disken filerna läses från högre hastighet? är det en mekanisk disk så är det väl genomsnittligt runt det man hamnar när man börjar kopiera/flytta filer iaf enligt min erfarenhet.

Ja 156 Mbit ser ut som nån sida har snurrdisk, brukar vara runt där man hamnar

Hårdiskarna garanterat. Testa göra en ramdisk på båda sidorna och skicka en fil sen så har du svar på om det är flaskhalsen.

Fler ideer om det inte är disken som begränsar:

Comhem (som inte finns längre) hade assymetriska hastigheter via koax, vilket var långsammare i den riktning du kör. De hade även symmetriska fiberabbonemang. Vad kör motparten?

Kör motparten WiFi?

Bandbredds-kollar-sajter och FTPS har en viktig skillnad: Trafiken ska krypteras/krypteras upp i det senare. Har bägge ändar tillräckligt med CPU för det? Hårdvaruaccelerering?

Småfiler över FTPS kommer antagligen vara långsammare än stora filer.

Allt som finns mellan punkterna nätverksmässigt kan begränsa, det spelar ingen större roll vad respektive ändpunkt får för hastighet mot en bandbredds-koll-sajt. Det kan vara intressant att köra egen okrypterad trafik, till exempel iperf3 över TCP för att kolla bandbredden.

@GarfieldPower, Och personen du laddar ifrån kan ladda upp/skicka i mer än 156 Kb/s?
Om "Ja" så kanske det är krypteringen som drar ned hastigheten, om det av någon anledning belastar hårdvaran såpass mycket.
Testa med vanlig FTP och se om ni får högre hastighet.

serenity@NEUTRON:~ $ dd if=/mnt/f/[...] of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.04869 s, 152 MB/s

vet inte men iaf min uplevelse när man skyfflar stora mängder data från mekanisk brukar det ösa upp till typ 100+MB/s i början för att sen sakta men säkert sjunka ner till typ 20-50MB/s max efter nåra hundra Mbyte data flyttad.

flyttar man bara når småfiler dock på nåra MByte var så brukar de dock bli ganska mycket högre avrage men när man ska flytta 10+Gbyte data i en stor gigantisk fil brukar de rätt snabt krypa ner mot krypfart.

prova byt port och se så någon sida på ISP inte har en throttle

Om det gäller externa USB-diskar under 10 TB storlek så är det typisk beteende med SMR-diskar och använder NTFS som filsystem när det är mycket småfiler, och än värre i windows som inte samlar skrivningar i RAM en god stund och sedan skriver sista versionen av skrivningar i block utan skriver mer löpande hela tiden och skriver om samma sektorer som den nyss skrivit på (främst i $MFT där man skiver minst 10 ggr på samma ställe med små förändringar i var överskrivning på samma sektorer per nyskapad fil) vilket är det skrivmönster som SMR-diskar hanterar allra sämst - med andra OS och filsystem som Linux, ext4 och BTRFS så kan man köra mycket mera (små)filer innan det går i väggen och med BTRFS kommer det förmodligen aldrig att märkas någon nedstrypning alls mot SMR-diskar hur mycket man än skriver.

Det andra som kan strypa ned mycket är krypteringen om det görs mjukvarumässigt utan HW-stöd i någon ända då kryptering är kostsamt och kanske hamnar på 16 - 20 MByte/s på en RPI4 eller liknande i ARM-baserad NAS utan HW-stöd för krypteringen.

OpenSSH kör med "chacha20-poly1305@openssh.com" som första valet i förhandling av chiper och det är ingen HW-stöd för denna i de flesta fallen och man kanske måste byta ordningsföljd på använda chiper så att aes128-ctr,aes192-ctr,aes256-ctr kommer före chacha200 i ssh_config-filen i ena eller båda ändarna om båda ändarna har AES-NI-stöd i sina CPU:er. Att chacha20 kommer före AES är för att den är mindre tung än AES att köra på plattformar som inte har AES-NI instruktioner i processorn (HW-AES).

på serversidan med AES-NI instruktioner för sin CPU så kanske det är lämpligt att kommentera bort chacha20 i ssh_config-filen då den forcerar även klienten att använda AES - med risken att det går ännu mer långsam om klientsidan inte har AES-NI stöd i libbar och CPU för sin SSH-klient men går betydligt fortare om de har det.

Sedan har jag för mig att skriva via SSH-porten så straffar det mycket på hastigheten om det är märkbara pingtider/delay mellan A och B-källan och det är inte tillfredsställande bra gjort i protokollet som sådan då den väntar på ack för var sänd paket innan den skickar nästa och med långa delayer drar det ned hastigheten väldigt mycket. Med openSSH 4.7 och senare på båda sidor så justeras paketstorleken mer aggressivt med hänsyn till fart och delayer och det kan gå bättre.

nu borde det vara senare versioner än openSSH 4.7 i dagens installationer - men kolla så att det inte släpar efter i tex openSSH i windows (fins numera default i windows 10 även om det inte är aktiverat - se hos Microsoft hur man aktiverar SSH-klient och SSH-server då det är lite poweshell-kommandon mm. som måste köras innan det fungerar som det skall )

Då tycker jag du ska säkerställa så personen inte kör över wifi

Peeringen mellan comhem och andra ISP är ganska ofta värdelös. Så ganska vanligt att maxspeeds begränsas av det. Hänt mig flera ggr att jag får ut 1/5 av speeden från vänner som har comhem.

Sen som andra säger så är ftp/ftps och bredbandskollen olika ting. Kan du slänga upp en fil på en apache lr nginx webbserver och be han ladda ner därifrån?

Då så då är det ur världen.
Har du samma problem när någon annan tar från dig?
Eller har han samma problem när han laddar ner från annat ställe?

En sak som inte nämnts hittills är att kolla att inte antivirus-mjukvaror ställer till och sölar ned i överföringen - om så - kanske det går att göra undantag för klientens trafik.

till detta är att prova att hämta filerna lokalt på servern och försäkra sig om att det inte flaskar där redan.

Maxar nerladdningen från din server Comhempersonens upload på 10Mbit? Be hen kolla på sin router/aktivitetshantererare (el. motsvarande).