Want a more just world? Be an unlikely ally (TEDx) [英語]
ひさしぶりのシャドウイングネタ。
Want a more just world? Be an unlikely ally
アメリカ南部出身の黒人女性なのに英語はなまりがなく、ゆっくり話すので聞きやすい。博士らしい。
不公平を是正するには、全く縁がなさそうな協力者が必要という話。
たとえば移民問題のために黒人が協力するとか。
cis allies: cis=cisgender (Wikipedia)
accomplice 共犯者
lead the charge 攻撃の先頭に立つ
be incensed by 激怒する
シャドウイング の難易度 ★
Want a more just world? Be an unlikely ally
アメリカ南部出身の黒人女性なのに英語はなまりがなく、ゆっくり話すので聞きやすい。博士らしい。
不公平を是正するには、全く縁がなさそうな協力者が必要という話。
たとえば移民問題のために黒人が協力するとか。
cis allies: cis=cisgender (Wikipedia)
accomplice 共犯者
lead the charge 攻撃の先頭に立つ
be incensed by 激怒する
シャドウイング の難易度 ★
Adventurer3でモデルに横ずれが出る問題を修正するクサビを作ってみた [技術]
FLASHFORGEのAdventurer3でモデルを出力すると時々横方向におかしな線が入ったり、途中で全体的に左や右にずれたりします。ネットを見ていたら「X方向に台座がズレる」と書いてある記事がここやここに見つかりました。これは3Dプリンターとしては致命的な欠陥のような気がします。手持ちのユーザーガイドには特にそんなこと書いてないし。出力中はビルドプレートを固定できるような構造にするとか、固定するための小物を付属品として同梱するとか、改善してほしいな。
さて、愚痴っていても解決しないので自分でなんとかしないと。Adventurer3のプラットフォームベースには左右の中央ににわずかな切り欠きがあります。奥行きは5cm程度です。上にリンクした記事ではこの隙間に爪楊枝を詰めたりして解決しているようなので、Adventurer3で詰め物を作ってみました。幅40mmx高さ8mmx厚さ最大2mm程度のクサビです。モデリングはBlenderで適当にやっつけました。このクサビを5cmの隙間に挟むと、少なくともビルドプレートを指でずらすことはできなくなり、固定できたようです。
全体像
立ててみた
隙間にはめたところ
このブログではGXやSTLは残念ながら添付できませんが、BlenderやFreeCADのようなアプリで簡単に作れますよ。
適当に出力したらぐちゃぐちゃになって、全部ヘッドに張り付いて一度失敗したものの、FlashPrintのパラメータの調整でなんとか綺麗に完成しました。こんな感じです。
Resolution: Hyper
Layer Height: 0.08mm
Print Speed: 10mm
Fill Density: 100%
Extruder: 210°C
Platform: 50°C
ラフトなし
サポートなし
使ったのはPLAのメタルフィラメントです。たまたま今それが刺さっているからという以外には特に理由はありません。フィラメントの使用量は16cm程度ですので、半端に余っていて使い道のないフィラメントを消費できます。所要時間も25分程度ですよ。
クサビを刺した状態でモデルを出力してみたところ極端な横ずれは解消できたようです。ところが今度はY(前後)方向のズレが気になるように。ヘッドが低すぎて時々造形物にぶつかり、その勢いでプラットフォームが動いてしまうのかも。次はヘッドを少し上げてみようかと思います。
注意点を一つ。これを右の隙間に刺して出力すると、なんらかの理由でモデルが右端の中央あたりにくる場合に送風口(ダクト)がクサビに引っかかっります。そのせいでプラットフォームを前後に移動させるギアから悲鳴がガリガリガリガリッ。壊れかねないので左の隙間に挿しましょう。左にも送風口があるタイプのヘッドもどこかで見た気がするのですが、その場合はクサビをちゃんと設計することをお勧めします。自作するのでなければ爪楊枝がお手軽ですかね。
2021/5/29追記
去年書いたこの記事はそれなりにアクセスがありますが、その後ネットを見ていて間違っている気がしてきました。
横ずれは出力したモデルにノズルが衝突するのが原因なので、ビルドプレートがずれないようにするのではなく、ノズルの高さを少し上げて、出力したモデルにノズルが衝突しないように調整して解決するのが正しそう。
さて、愚痴っていても解決しないので自分でなんとかしないと。Adventurer3のプラットフォームベースには左右の中央ににわずかな切り欠きがあります。奥行きは5cm程度です。上にリンクした記事ではこの隙間に爪楊枝を詰めたりして解決しているようなので、Adventurer3で詰め物を作ってみました。幅40mmx高さ8mmx厚さ最大2mm程度のクサビです。モデリングはBlenderで適当にやっつけました。このクサビを5cmの隙間に挟むと、少なくともビルドプレートを指でずらすことはできなくなり、固定できたようです。
全体像
立ててみた
隙間にはめたところ
このブログではGXやSTLは残念ながら添付できませんが、BlenderやFreeCADのようなアプリで簡単に作れますよ。
適当に出力したらぐちゃぐちゃになって、全部ヘッドに張り付いて一度失敗したものの、FlashPrintのパラメータの調整でなんとか綺麗に完成しました。こんな感じです。
Resolution: Hyper
Layer Height: 0.08mm
Print Speed: 10mm
Fill Density: 100%
Extruder: 210°C
Platform: 50°C
ラフトなし
サポートなし
使ったのはPLAのメタルフィラメントです。たまたま今それが刺さっているからという以外には特に理由はありません。フィラメントの使用量は16cm程度ですので、半端に余っていて使い道のないフィラメントを消費できます。所要時間も25分程度ですよ。
クサビを刺した状態でモデルを出力してみたところ極端な横ずれは解消できたようです。ところが今度はY(前後)方向のズレが気になるように。ヘッドが低すぎて時々造形物にぶつかり、その勢いでプラットフォームが動いてしまうのかも。次はヘッドを少し上げてみようかと思います。
注意点を一つ。これを右の隙間に刺して出力すると、なんらかの理由でモデルが右端の中央あたりにくる場合に送風口(ダクト)がクサビに引っかかっります。そのせいでプラットフォームを前後に移動させるギアから悲鳴がガリガリガリガリッ。壊れかねないので左の隙間に挿しましょう。左にも送風口があるタイプのヘッドもどこかで見た気がするのですが、その場合はクサビをちゃんと設計することをお勧めします。自作するのでなければ爪楊枝がお手軽ですかね。
2021/5/29追記
去年書いたこの記事はそれなりにアクセスがありますが、その後ネットを見ていて間違っている気がしてきました。
横ずれは出力したモデルにノズルが衝突するのが原因なので、ビルドプレートがずれないようにするのではなく、ノズルの高さを少し上げて、出力したモデルにノズルが衝突しないように調整して解決するのが正しそう。
Blender extrusion, normal direction, and the order of vertices [技術]
I wrote an article about Blender extrusion about a year ago. I now understand the logic behind extrusion, verticies, and direction of normals:
Order the vertices counter-clockwise and pull them up. The normals will be directed outward.
It appears like this is a common practice for usual CAD programs. Related articles:
Autodesk
FreeCAD Forum
Stack Overflow
File Format
This is a description about STL file.
Order the vertices counter-clockwise and pull them up. The normals will be directed outward.
It appears like this is a common practice for usual CAD programs. Related articles:
Autodesk
The order of vertices around the face determine the direction of the face (whether a side of the polygon is the front or the back). For example, if you place vertices in a clockwise direction, the face normal points downward. If you place vertices in a counter-clockwise direction, the face normal points upward. See Create a polygon mesh.
FreeCAD Forum
Vertices go clockwise around the normal direction.
No, they're counter-clockwise normally.
Stack Overflow
The vertices should be in counter-clockwise order when the vertices are viewed from outside of the object. (Obviously, viewing from inside the object they are then in clockwise order).
The normal should point outward.
File Format
This is a description about STL file.
- The direction of the normal is outward
- The vertices are listed in counter-clock-wise order from outside, obeying the right-hand rule.
Failed attempt to tune long distance file transfer across continent between Linux and MacOS [技術]
Conditions
I live in Japan, using a Macbook with MacOS Catalina. A CentOS file server exists at the other end of the Eurasian continent, 9 time zones away. It is maintained by some other organization and I have no control over its behaviour, except by configuring parameters on the client side.
I want to pull 30+ files, >1GB in total, from the file server over HTTPS using curl. It completes quite fast if I use a Linux on Intel NUC that resides in our office. It takes less than 20 minutes. However, it takes more than 6 hours from my Macbook with the same network conditions, so my Macbook is more than 10 times slower than the Linux box with regard to file transfer speed in this specific setup. If I pull a huge file from a CDN site with my Macbook, it is very fast. So the LAN and the local ISP line are fine at least.
To ensure the User-Agent does not affect the transfer speed, I used Linux UA on Mac and vice versa and measured the speed using curl on both platforms. It did not make any difference: Linux client is always 10+ times faster than Macbook client.
Observations
So I captured packets on my Macbook as well as on the Linux in the office and compared them. There are several notable differences in the two packet captures.
1. Macbook starts TCP handshake with ECN and CWR flags turned on. This is the indication that the client wants to establish a TCP connection with ECN (Explicit Congestion Notification). (blog article, Wikipedia)
On the other hand, Linux client initiates TCP handshake without ECN flags.
2. Packets taken on the Linux box have lots of TCP segments with their sizes much larger than the usual segment size (like 12,378 bytes instead of around 1,400 bytes). If I specify "tcp.len > 1448" display filter in Wireshark, it filters out all packets from the Mac pcap. On the other hand, a display filter of "tcp.len > 10000" shows more than 80 packets on the Linux pcap. This is an indication that the file server (Linux) uses TCP segmentation offload against the Linux client, but not against MacOS.
Maybe the server does not like the advertised window size value, 65535, larger than its own, 28960, or maybe ECN is the root cause, or maybe something else. Who knows. This needs experimenting.
Increase mbuf clusters
This article describes a way to increase mbuf clusters on MaOS. Recent versions of MacOS has SIP, and you need to boot to the recovery mode if you want to change boot-args by the nvram command. Then also execute the sysctl commands to tune TCP parameters as described in the page.
Result: no improvements. File transfer using curl seems slower with the changes.
TCP parameters
This article is a bit outdated, but has some TCP tuning tips. I have tried them along with the above technique, but it did not help speedup the transfer either.
That's as far as I could get. Does anyone know how such file transfers can be sped up? I am hoping that there is a way for MacOS client to cause the Linux file server to use TCP segmentation offload. I just cannot find out how.
I live in Japan, using a Macbook with MacOS Catalina. A CentOS file server exists at the other end of the Eurasian continent, 9 time zones away. It is maintained by some other organization and I have no control over its behaviour, except by configuring parameters on the client side.
I want to pull 30+ files, >1GB in total, from the file server over HTTPS using curl. It completes quite fast if I use a Linux on Intel NUC that resides in our office. It takes less than 20 minutes. However, it takes more than 6 hours from my Macbook with the same network conditions, so my Macbook is more than 10 times slower than the Linux box with regard to file transfer speed in this specific setup. If I pull a huge file from a CDN site with my Macbook, it is very fast. So the LAN and the local ISP line are fine at least.
To ensure the User-Agent does not affect the transfer speed, I used Linux UA on Mac and vice versa and measured the speed using curl on both platforms. It did not make any difference: Linux client is always 10+ times faster than Macbook client.
Observations
So I captured packets on my Macbook as well as on the Linux in the office and compared them. There are several notable differences in the two packet captures.
1. Macbook starts TCP handshake with ECN and CWR flags turned on. This is the indication that the client wants to establish a TCP connection with ECN (Explicit Congestion Notification). (blog article, Wikipedia)
On the other hand, Linux client initiates TCP handshake without ECN flags.
2. Packets taken on the Linux box have lots of TCP segments with their sizes much larger than the usual segment size (like 12,378 bytes instead of around 1,400 bytes). If I specify "tcp.len > 1448" display filter in Wireshark, it filters out all packets from the Mac pcap. On the other hand, a display filter of "tcp.len > 10000" shows more than 80 packets on the Linux pcap. This is an indication that the file server (Linux) uses TCP segmentation offload against the Linux client, but not against MacOS.
| Server (far away) | Client 1 | Client 2 | ||
|---|---|---|---|---|
| OS | CentOS | CentOS 6.8 | MacOS Catalina | |
| Application | Apache 2.4.6 | Curl 7.19.7 | Curl 7.64.1 | |
| File Transfer Speed from the Server | - | ~1.2MB/s | <100KB/s | |
| TCP Header | Window Size Value | 28960 | 14600 | 65535 |
| Explicit Congestion Notification | on if asked | off | on | |
| Segmentation Offload (server) | - | on | off | |
| Maximum Segment Size | 1380 for Client 1 1460 for Client 2 | 1460 | 1460 | |
| Window Scale | 7 | 7 | 6 | |
| Selective ACK | permitted | permitted | permitted | |
| Max Ethernet Frame Received by tcpdump | - | 16,482 bytes | 1,514 bytes | |
Maybe the server does not like the advertised window size value, 65535, larger than its own, 28960, or maybe ECN is the root cause, or maybe something else. Who knows. This needs experimenting.
Increase mbuf clusters
This article describes a way to increase mbuf clusters on MaOS. Recent versions of MacOS has SIP, and you need to boot to the recovery mode if you want to change boot-args by the nvram command. Then also execute the sysctl commands to tune TCP parameters as described in the page.
Result: no improvements. File transfer using curl seems slower with the changes.
TCP parameters
This article is a bit outdated, but has some TCP tuning tips. I have tried them along with the above technique, but it did not help speedup the transfer either.
That's as far as I could get. Does anyone know how such file transfers can be sped up? I am hoping that there is a way for MacOS client to cause the Linux file server to use TCP segmentation offload. I just cannot find out how.
